news:CAF4+nEEYKD4TEKrv1sg=1wG+YJ=ZLtEOg_nNHx6k=-0C71-KkA@mail.gmail.com
Sees reasonable. While you are at it, you might complete the I* with IANA...
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com
On Mon, Jul 30, 2012 at 9:04 PM, Barry Leiba <barryleiba@computer.org> wrote:
> I have just posted the draft cited below, to adjust the NomCom
> eligibility rules to make the following change:
>
> RFC 3777 excludes from eligibility as NomCom volunteers:
> - members of the ISOC Board of Trustees
> - "sitting members" of the IAB
> - "sitting members" of the IESG
>
> The IAOC did not exist when that was written, and there are questions
> about who, exactly, are "sitting members".
>
> This draft excludes from eligibility as NomCom volunteers:
> - members of the ISOC Board of Trustees
> - "sitting members" of the IAB
> - "sitting members" of the IESG
> - "sitting members" of the IAOC
>
> This draft clarifies that those exclusions:
> - DO include the ex-officio members
> - DO NOT include the liaisons (unless, of course, they're excluded
> by another rule)
>
> This draft also excludes from eligibility as NomCom volunteers paid employees:
> - the Secretariat
> - the RFC Editor
>
> Comments, please.
>
> Barry
>
>> Filename: draft-leiba-3777upd-eligibility
>> Revision: 00
>> Title: Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership
>> Creation date: 2012-07-30
>> WG ID: Individual Submission
>> Number of pages: 4
>> URL: http://www.ietf.org/internet-drafts/draft-leiba-3777upd-eligibility-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-leiba-3777upd-eligibility
>> Htmlized: http://tools.ietf.org/html/draft-leiba-3777upd-eligibility-00
>>
>>
>> Abstract:
>> RFC 3777 specifies that "sitting members" of the IAB and IESG "may
>> not volunteer to serve on the nominating commitee". Since that
>> document was written the IAOC was formed, and that body is not
>> covered by RFC 3777. There is also uncertainty about whether ex-
>> officio members and liaisons are included as "sitting members". This
>> document clarifies those situations.
news:50180A18.2090008@bogus.com
On 7/31/12 9:15 AM, Randy Bush wrote:
>> I'd probably also recommend excluding paid employees of ISOC. I cannot
>> really think of rationale that applies to the secretariat staff but
>> not ISOC.
> perhaps we should take the leap of assuming folk are adults here (i
> realize it is a stretch), and not start a black-list with no proof of
> termination.
One imagines an ISOC employee participating in the IETF activity on the
same basis as everyone else who participates in the IETF activity, as
individuals. if their role is covered by an ex officio office exclusion
that seems sufficient.
> randy
>
news:6.2.5.6.2.20120710081323.08c9bcf8@resistor.net
Hi Andreas,
At 04:28 10-07-2012, Andreas Petersson wrote:
>I interpret it the other way around.
>It makes a deployer aware that there is also end user expectations
>to take into considerations.
>Removing it may work as well, but I think that less well reflects the
>discussion on the apps-list.
There is a thread at
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06592.html
of the working group discussions. There were views from three
persons. I am in agreement with Alissa on that text. I'll "+1" her
message at
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06664.html
>I think that will make parsing harder, and give no benefit at all.
It allows for more random bits of information.
Regards,
-sm
news:4FF18572.2000905@cs.tcd.ie
Hi Martin,
On 07/02/2012 12:07 PM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/26 20:26, Stephen Farrell wrote:
>>
>> Hi again Martin,
>>
>> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>>> So the question is really, what's the use case, and what's just a
>>> consequence of that use case. If confirmation of already available
>>> resources (e.g. like a fingerprint) is the (main?) use case, and the
>>> greater weight on "speakability" just a design consequence, then it
>>> makes sense to have two separate things.
>>
>> Yes, confirmation is the main current use-case for nih as I understand
>> it and have said previously.
>
> I sincerely wish you had said this so clearly much, much earlier, or
> even better that it had been in the draft in cristal clear language. We
> could have avoided a lot of useless discussion.
I agree this has been harder than it ought have been for some
reason. I guess that just happens sometimes.
>
>> (Of course the resource might not yet
>> be present, so "already available" isn't quite right, but that's a
>> nit.)
>>
>> Have we beaten this to death sufficiently now? I hope so;-)
>>
>> If you want to suggest a sentence that says that, feel free.
>
> I really don't think it should be my job to explain this. There are
> enough coauthors on the draft who should be in a much better position
> than myself to write such text :-(.
Well, you seemed motivated:-)
> Anyway, here is a try:
>
> - In the abstract, replace "and binary and human "speakable" formats for
> these names" by ", a binary form, and a form for confirming the presence
> (or absence) of resources".
>
> - In the introduction, replace "and a
> human-speakable text form that could be used, e.g. for reading out
> (parts of) the name over a voice connection." with
> "and a form optimized for confirming the presence (or absence) of
> resources by humans.".
>
> - Change the title of Section 7 from "Human-speakable Format" to "Format
> for Resource Confirmation"
>
> - Replace the first sentence at the start of Section 7 to say:
> There is often a need for humans to confirm that a particular resource,
> e.g. a public key, is already present, or to discover its absence.
>
> - Change "("speaking" the value of an ni URI)" to "confirm the presence
> or absence of a resource")
>
> - Nuke the second paragraph of section 7 (the one that starts with "The
> justification for using a URI"). The stuff it says about IDNs, for
> example, isn't really appropriate for IETF standardization.
>
> - In the example section, change "Human-speakable form of a name" to
> "Form for resource confirmation" (three occurrences).
I could live with more-or-less all of that. Will check if coauthors
can similarly. I think "human-speakable" still needs to be mentioned
though, since that's why its designed as it is, but I like those
changes generally.
> I'd also change the "nih:" scheme to something like "fingerprint:", and
> allow the insertion of delimiter characters (allowing e.g.
> nih:3;5326-9057-e12f-e2b7-4ba0-7c89-2560a2;f instead of
> nih:3;53269057e12fe2b74ba07c892560a2;f because the former should be much
> easier to manipulate by humans),
Would rather not change the uri scheme name at this point, unless
a load of people prefer it, but the idea of optional "-" delimiters
seems useful all right.
> but I guess I'd again be shot down for
> "proposing something like this at such a late date" (I note we are still
> in IETF Last Call).
Just:-) But improvements don't stop at the end of IETF LC and your
suggestions above are, I think, improvements.
Any other opinions before I go make changes along these lines?
Cheers,
S.
>
>
> Regards, Martin.
>
>
news:CAJNg7VK9OJNdtBb4+F3ZepvgpwuXQ_30ung_Y91m--g1a+CpfA@mail.gmail.com
On Sun, Jul 22, 2012 at 11:31 AM, John Levine <johnl@taugh.com> wrote:
>> Yes, we typically then point out that much of what they want is
>> available on line, and frequently negotiate with opposing counsel to
>> moderate demands for depositions, etc., but, in the end, we propose,
>> the judge and opposing counsel dispose. That won't change.
>
> I'd want to set the depo rate high enough that if someone has to be
> deposed, he or she will at least feel that the money makes up for
> the hassle.
>
> For people with unique skills or knowledge, $800/hr is not unusual.
> So long as the rate is published ahead of time, you're not going to
> get much argument. ("Yes, we know it's high. But we've already told
> you how to download stuff yourself for free.")
>
Please note : out of pocket expenses (if someone has to travel to a
hearing, say) would be reimbursed, but
IETF volunteers will not be paid from these fees.
Regards
Marshall
> R's,
> John
news:CF472A8775DF4CDEEA6A1325@JcK-HP8200.jck.com
--On Friday, July 20, 2012 06:07 -0700 IETF Administrative
Director <iad@ietf.org> wrote:
> The IAOC is seeking community feedback on a proposed policy by
> the IAOC to impose fees to produce information and
> authenticate documents in response to subpoenas and other
> legal requests.
>...
> Before adopting a policy the IAOC would like feedback on this
> before making a decision. Comments appreciated to
> ietf@ietf.org by 6 August 2012.
Seems entirely reasonable. Knowing how much effort some of
these requests can produce, I do wonder if the fees are a bit
too low but trust that the IAOC has determined that they will at
least cover costs.
john
news:C4DFC40DF886B4A5E4B10B2A@7AD4D3FB4841A5E367CCF211
--On Monday, 30 July, 2012 21:04 -0400 Barry Leiba
<barryleiba@computer.org> wrote:
> I have just posted the draft cited below, to adjust the NomCom
> eligibility rules to make the following change:
>...
> This draft also excludes from eligibility as NomCom volunteers
> paid employees:
> - the Secretariat
> - the RFC Editor
Barry,
I'll try to avoid going over the top this time (as I told you in
person, the "exclude WG Chairs" suggestion was entirely to
promote discussion rather than a proposal), but...
If one wants to exclude the Secretariat and RFC Editor staff --
presumably on the basis that they are appointed by, and draw
their salaries from, bodies partially appointed by the Nomcom --
then it seems to me that:
(1) You should explicitly exclude the IAD (for completeness of
the list and to avoid debate about whether he is already
excluded by the "sitting member" and/or "ex-officio" rules for
the IAOC.
(2) You should exclude anyone from the pool who has bid on or
held an IAOC-awarded contract in some period of time (I would
suggest a year) or who has bid on such a contract during that
period. Anyone who actually serves on the Nomcom should also be
excluded from bidding on any such contract during their Nomcom
terms and perhaps for a year (or more?) thereafter.
Much of this is about appearances. For example, I would hope
that sitting ADs would have better sense than to volunteer for
the Nomcom even if the rules technically permitted that. Nor
would I expect Secretariat staff to volunteer (as far as I know,
none ever has despite the current rules apparently permitting
that). But relatively short-term contractors are presumably
no different from the Secretariat in either the award or
management processes and the potential for patronage and
cronyism are actually much greater.
john
news:CAK+d4xtwD+JjY7ZQzkB=x=iJMQadn8QF3Z=YcZuX_mNFJ6s9vw@mail.gmail.com
I completely agree that it's reasonable to be able to recover these
costs, and trust the IAOC to set the fees to a level commensurate for
cost recovery. There's no reason why the IETF should be financially
burdened by lawsuits between external parties in which the IETF is not
a principal party to the suit.
Cheers,
Andy
On Fri, Jul 20, 2012 at 9:07 AM, IETF Administrative Director
<iad@ietf.org> wrote:
> The IAOC is seeking community feedback on a proposed policy by the IAOC to impose
> fees to produce information and authenticate documents in response to subpoenas and
> other legal requests.
>
> The IETF receives requests for information, documentation, authentication or other
> matters through subpoenas and less formal means that require manpower and materials
> to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF
> responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three
> other legal requests for authenticated documents.
>
> Each such request is time sensitive and involves the IETF Counsel, the IAD, and members
> of the IAOC, who together form the Legal Management Committee, to rapidly analyze and
> identify the means for satisfying the request. Often there is a need to retain outside counsel,
> especially in cases that might lead to depositions or court testimony.
>
> The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover
> costs associated with such efforts.
>
> The draft policy entitled Draft Fee Policy for Legal Requests can be found
> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Before adopting a policy the IAOC would like feedback on this before making a
> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
news:7CB6858E-9F28-4BA7-8683-3903F521C2A0@checkpoint.com
On Jul 20, 2012, at 4:52 PM, Worley, Dale R (Dale) wrote:
> On Fri, 2012-07-20 at 06:07 -0700, IETF Administrative Director wrote:
>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Assuming that the IAOC has set these fees to be close to the actual
> costs of servicing legal requests, I see no objection to the policy.
It's hard to gauge the actual costs. What is an hour spent by a volunteer worth? Counsel fees can be measured and covered, but the IAOC members are spending their own (or their employer's) resources on this.
Although a lot of the work is done by volunteers, in this case we're selling their work to others, and we should not sell it cheaply.
I support this policy.
Yoav
news:4FFC9143.40407@viagenie.ca
On 07/10/2012 04:03 PM, Sam Hartman wrote:
> >> and MUST NOT support the third-party option.
>
> Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it could
> Simon> be used in CGN scenarios. If that is right, wouldn't it then make
> Simon> sense to allow THIRD_PARTY on CGNs?
>
> I don't think you can describe an subscriber-facing network of an ISP as
> "fully trusted."
> The text added to 13.1 might permit third_party to be used by an
> administrative web service within an ISP but certainly not by customers
> of that ISP.
> I'd be OK with "MUST NOT allow the third_party option for traffic
> recieved from customer-facing interfaces."
> or "MUST NOT allow the third_party option in requests received on the
> internal network."
> Then that still permits the case of third_party for administration
> motivating the text in 13.1.
Makes sense to me.
> >> My second concern is with section 8.
> >> This section says that spoofing is a concern of DOS, notes that ingress
> >> filtering is a defense and makes no recommendation.
> >>
> >> I believe spoofing is a significantly greater concern than DOS. As an
> >> example, I can spoof traffic from you to create an inbound hole towards
> >> one of your ports.
>
> Simon> Is this a new attack vector introduced by CGN? Without NAT, there's no
> Simon> need for a "hole", anyone can send traffic to any of a subscriber's
> Simon> ports...
>
> I find it difficult to answer that question. I'd say that it is likely
> an unexpected assumption for someone behind a NAT. It is a
> vulnerability of CGNs over other NATs, but perhaps not a vulnerability
> of CGNs over no NAT or firewall at all.
> Why do we care whether it's new? Is it actually bad if we end up
> describing a related attack and recommending people deploy in a manner
> that avoids it?
The DoS part is new. If an evil subscriber creates mappings in your
stead, you may be DoSed. This attack vector does not exist with neither
single-user NAT nor no NAT at all. That's why we mention it in the
security considerations.
I don't think it is useful to recommend ingress filtering to prevent
unwanted traffic because it would rely on an unrealistic assumption of a
new security benefit that a CGN would provide. CGN does not prevent a
subscriber from receiving traffic from anyone. That's true even with
ingress filtering.
How about adding a sentence like...
"CGN as described in this document does not provide any security
benefits over either single-user NAT or no NAT at all."
I don't think we have any power to change a subscriber's unreasonable
assumptions, but we can at least honestly say to operators that they're
not buying any security with CGN.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:D7CD7207-FCDD-46FF-85B3-501DD0558B13@gmail.com
Thanks for the review.
The table in section 2.2 in the -03 draft only has the entries that need to be updated. Besides the 3 entries that are now Reserved, but the references for some other entries have been fixed. I removed the correct, unchanged entries for readability (the mnemonics for some of the entires skewed the table and made it difficult to read).
Scott
===================================
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================
On Jul 14, 2012, at 7:18 AM, Samuel Weiler wrote:
> General comment: no objection.
>
> The table in section 2.2 is odd: in addition to the three entries being updated, it lists some BUT NOT ALL of the other assignments already made. I suspect that's a historical artifact. My suggestion: since the intro text in that section says "The list of .. registry entry changes is below", remove all entries that aren't changing. That will make the reader's job easier.
>
> -- Sam Weiler
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
news:20120704184933.79868.qmail@joyce.lan
>NANOG is around 500 attendees. I daresay exposure to the average nanog
>attendee is worth more, but ultimately the best feedback in that regard
>will likely come from the sponsors.
IETF is bigger, but on the other hand, IETF attendees probably spend
less per capita on equipment than NANOGers do.
It's an experiment, if we're turning away sponsors and people think it
was overall a success, we can raise the price. If not, well, we can
do something else.
R's,
John
news:009801cd68dd$c3e68ce0$4bb3a6a0$@us
As a working assumption let's say at least 750 USD or Euros per hour to
calculate cost recovery.
-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of John
C Klensin
Sent: Friday, July 20, 2012 10:40 AM
To: IETF Administrative Director
Cc: ietf@ietf.org
Subject: Re: Feedback Requested on Draft Fees Policy
--On Friday, July 20, 2012 06:07 -0700 IETF Administrative Director
<iad@ietf.org> wrote:
> The IAOC is seeking community feedback on a proposed policy by the
>IAOC to impose fees to produce information and authenticate documents
>in response to subpoenas and other legal requests.
>...
> Before adopting a policy the IAOC would like feedback on this before
>making a decision. Comments appreciated to ietf@ietf.org by 6 August
>2012.
Seems entirely reasonable. Knowing how much effort some of these requests
can produce, I do wonder if the fees are a bit too low but trust that the
IAOC has determined that they will at least cover costs.
john
news:50107D3E.2030902@mulligan.com
And I could possibly use a room for Thursday night...
On 07/25/2012 05:06 PM, Dave Crocker wrote:
>
>
> On 7/25/2012 3:54 PM, Randall Gellens wrote:
>> I may have a room at the Hyatt at CAD 194 (includes breakfast) for the
>> full IETF week. If anyone wants it, please let me know right away.
>
>
> I could use a room at the Hyatt, but only for that Friday night.
>
> d/
news:m2mx2tsazr.wl%randy@psg.com
> As for the Ramadan issue
you deserve to deal with surly folk such as i when we have not eaten for
twelve hours.
randy
news:20120722153118.60473.qmail@joyce.lan
> Yes, we typically then point out that much of what they want is
> available on line, and frequently negotiate with opposing counsel to
> moderate demands for depositions, etc., but, in the end, we propose,
> the judge and opposing counsel dispose. That won't change.
I'd want to set the depo rate high enough that if someone has to be
deposed, he or she will at least feel that the money makes up for
the hassle.
For people with unique skills or knowledge, $800/hr is not unusual.
So long as the rate is published ahead of time, you're not going to
get much argument. ("Yes, we know it's high. But we've already told
you how to download stuff yourself for free.")
R's,
John
news:65992FFB-CEE6-4D0A-B6EC-9379063F4FAC@checkpoint.com
On Jul 21, 2012, at 10:00 AM, Eliot Lear wrote:
> I'd support a date change for IETF 95 but it should be the week of the
> 14th to take into account Palm Sunday and Good Friday. As to Ramadan, I
> too would like to understand if there is a need to take this holiday
> into account, and what would be the practical way to do that?
My Moslem coworkers, some more observant, some less so, all come to work on Ramadan. Ramadan lasts a whole month (well, a whole lunar cycle), and involves fasting from sunrise to sunset. This is relatively OK when Ramadan falls in winter, but more painful when it falls in summer.
This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
Yoav
news:CFDBFE9825F3FE036F1B296D@JcK-HP8200.jck.com
--On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
<presnick@qualcomm.com> wrote:
> Perhaps I'm just being contrarian today, but I *do* think this
> document should be BCP and not Informational. It is not a
> requirements document in the sense that it is laying out
> requirements for future protocol documents being developed by
> a WG; it is a consensus document listing the requirements for
> the operation and administration of a type of device. If that
> doesn't fall within the 2nd paragraph of RFC 2026 section 5, I
> don't know what does.
Just to be disagreeable...
I think "requirements for the operation and administration of a
type of device" puts it squarely into the "Applicability
Statement" range, in part of permit testing of those
requirements and advancement along the standards track. Of
course, the precedent is RFCs 1122 and 1123 which requirements
for operation and administration as well as for protocol
conformance and are clearly applicability statements (and more
or less the prototype for that category).
john
news:201207201901.q6KJ1Eaj030858@mtv-core-3.cisco.com
At 12:58 PM 7/20/2012, Richard L. Barnes wrote:
>For convenience, the complete list:
><http://www.interfaithcalendar.org/2016.htm>
outstanding - now we can't meet that whole year... ;-)
>On Jul 20, 2012, at 1:44 PM, Andrew G. Malis wrote:
>
> > As long as you don't go any later than the week of April 10 - the week
> > of April 17 runs into the start of Passover.
> >
> > Thanks,
> > Andy
> >
> > On Fri, Jul 20, 2012 at 1:29 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> >>
> >> On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
> >>
> >>> On 7/20/12 09:06 , IETF Administrative Director wrote:
> >>>> The IAOC is seeking community feedback on a proposed date
> change for IETF 95
> >>>> scheduled for March 2016.
> >>>>
> >>>> Currently IETF 95 is scheduled for 27 March to 1 April
> 2016. 27 March is Easter.
> >>>>
> >>>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March
> 2016 and would like
> >>>> feedback on those dates before making a decision. Comments
> appreciated to ietf@ietf.org
> >>>> by 6 August 2012.
> >>>
> >>> 20 march is palm sunday on the western calender.
> >>>
> >>> If one's a conflict presumably the other is too...
> >>
> >> I personally avoid being away from home on Easter, and would
> prefer that the IETF meeting avoid it.
> >>
> >> Yes, Palm Sunday is a question, but not quite on the same scale
> as Easter. I will note, however, that Good Friday (the Friday
> before Easter) is a national holiday in a number of countries.
> People schedule vacations around that weekend.
> >>
> >> My suggestion: take the week of April 3 or later.
news:alpine.BSF.2.00.1207221654200.31418@joyce.lan
> I did not do them any favor - I did the IETF a favor (as the then ISOC VP for Standards)
Really, if you didn't make the opposing party pay for your time, you did
them a favor. It's absolutely expected to pay hostile witnesses for their
depo time. (If nobody mentioned it, why would they offer to pay if you
were willing to do it for free?)
If it happens again, pick the highest rate you think you're worth and
double it. If you want, donate the money to the IETF trust and encourage
them to use it for better cookies.
R's,
John
news:01OIHVR9FZ6E0006TF@mauve.mrochek.com
> > I'd probably also recommend excluding paid employees of ISOC. I cannot
> > really think of rationale that applies to the secretariat staff but
> > not ISOC.
> perhaps we should take the leap of assuming folk are adults here (i
> realize it is a stretch), and not start a black-list with no proof of
> termination.
+1 on all points, including the stretch part.
Ned
P.S. I'm not a big fan of "for appearance's sake". All too often it proves to
be a path to madness.
news:79A97772-4F3D-4BA0-9A1C-6881E6780FB1@vigilsec.com
Julian:
> No, I was just trying to understand *why* the archive can't be at <http://www.ietf.org/tao/archive>.
I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory.
Russ
news:1343673357.26306.5.camel@gwz-laptop
On Mon, 2012-07-30 at 19:26 +0100, Stephen Farrell wrote:
> I agree with the comments about 2804.
>
> I do note a lot of April 1 RFCs in the references
> though, so maybe its all a joke.
Gotta be!
>
> S
>
> On 07/30/2012 06:51 PM, Brian E Carpenter wrote:
> > Yes, Scott, that is correct, sorry for my poor phrasing.
> >
> > Brian
> >
> > On 30/07/2012 17:33, Scott O Bradner wrote:
> >> 2804 does not say not to talk about such things - or that such documents should
> >> not be published as RFCs - 2804 says that the IETF will not do standards work
> >> in this area
> >>
> >> Scott
> >>
> >> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
> >>
> >>> Under the long-standing IETF policy defined in RFC 2804, I trust
> >>> we will not be discussing this draft, or
> >>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
> >>>
> >>> Regards
> >>> Brian Carpenter
> >>>
> >>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >>>>
> >>>>
> >>>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
> >>>> Author(s) : Shankar Raman
> >>>> Balaji Venkat Venkataswami
> >>>> Gaurav Raina
> >>>> Vasan Srini
> >>>> Bhargav Bhikkaji
> >>>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
> >>>> Pages : 12
> >>>> Date : 2012-07-30
> >>>>
> >>>> Abstract:
> >>>> In models of Single-AS and inter-provider Multi- Protocol Label
> >>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
> >>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
> >>>> models like VPLS and the like do not have any provider provisioned
> >>>> methods of lawful intercept that are comprehensive, quick and easy to
> >>>> provision from one single point. More particularly the auto-
> >>>> provisioning of lawful intercept for all sets of streams travelling
> >>>> between VPN sites and consequent re-direction of these streams to the
> >>>> appropriate government network has not been covered without multiple
> >>>> instances of having to configure the intercept at various points in
> >>>> the network both in the Single-AS case and the Inter-Provider VPN
> >>>> case.
> >>>>
> >>>> this paper, we propose a technique which uses a set of pre-defined
> >>>> labels called Lawful Intercept labels and a method for provisioning
> >>>> lawful intercept amongst the various PE devices using these labels
> >>>> both in the Single-AS and the inter-provider VPN cases. A single
> >>>> point of configuration is the key to this idea. The intercepted
> >>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
> >>>> participating in the VPN. A technique called the Domino-effect
> >>>> provisioning of these Label-based Provider Provisioned Lawful
> >>>> Intercept mechanism is also outlined.
> >>>>
> >>>>
> >>>> The IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
> >>>>
> >>>> There's also a htmlized version available at:
> >>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
> >>>>
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>
> >>>> _______________________________________________
> >>>> I-D-Announce mailing list
> >>>> I-D-Announce@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html
> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>
> >>
> >>
> >
> >
news:1095943C-3926-4697-AF13-C4C4D7A5505E@cisco.com
On Jul 20, 2012, at 6:08 PM, Paul Hoffman wrote:
> As for the Ramadan issue: we've had IETF meetings during Jewish holidays a few times, and folks dealt with it as best they can. If there are some accommodations that can be made at any IETF meeting for different holidays of major religions, I would bet that IETF Secretariat would be glad to hear them.
It comes down to adding them to the clash list...
news:C51A593C-2280-436D-95BC-FD06DEAD3049@kirei.se
On 2012-07-18, at 01:06, Russ Housley wrote:
> I think you missed my point. In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier. I do not see a similar concept here.
Russ, you are right. There is no such concept in DNSSEC (yet). Simply by looking at the signed data, there is no way of determining under what policy the data has been signed. Interested parties must stay informed using the process specified in section 1.4.3 (Specification change procedures) of the DPS.
Generally speaking, DNSSEC signatures are short-lived. From the time a new policy is in effect, old signatures will be flushed out within days. However, if there are significant changes made to the policy which materially affect the security posture of the zone, there may be several reasons to roll the signing key(s) and to indicate this in the DPS. This way, the validating party will be able to determine under what policy a signature has been generated, and act accordingly.
- Fredrik
news:5016D1DB.2040600@cs.tcd.ie
I agree with the comments about 2804.
I do note a lot of April 1 RFCs in the references
though, so maybe its all a joke.
S
On 07/30/2012 06:51 PM, Brian E Carpenter wrote:
> Yes, Scott, that is correct, sorry for my poor phrasing.
>
> Brian
>
> On 30/07/2012 17:33, Scott O Bradner wrote:
>> 2804 does not say not to talk about such things - or that such documents should
>> not be published as RFCs - 2804 says that the IETF will not do standards work
>> in this area
>>
>> Scott
>>
>> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>>
>>> Under the long-standing IETF policy defined in RFC 2804, I trust
>>> we will not be discussing this draft, or
>>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>>
>>> Regards
>>> Brian Carpenter
>>>
>>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
>>>> Author(s) : Shankar Raman
>>>> Balaji Venkat Venkataswami
>>>> Gaurav Raina
>>>> Vasan Srini
>>>> Bhargav Bhikkaji
>>>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>>> Pages : 12
>>>> Date : 2012-07-30
>>>>
>>>> Abstract:
>>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>>> models like VPLS and the like do not have any provider provisioned
>>>> methods of lawful intercept that are comprehensive, quick and easy to
>>>> provision from one single point. More particularly the auto-
>>>> provisioning of lawful intercept for all sets of streams travelling
>>>> between VPN sites and consequent re-direction of these streams to the
>>>> appropriate government network has not been covered without multiple
>>>> instances of having to configure the intercept at various points in
>>>> the network both in the Single-AS case and the Inter-Provider VPN
>>>> case.
>>>>
>>>> this paper, we propose a technique which uses a set of pre-defined
>>>> labels called Lawful Intercept labels and a method for provisioning
>>>> lawful intercept amongst the various PE devices using these labels
>>>> both in the Single-AS and the inter-provider VPN cases. A single
>>>> point of configuration is the key to this idea. The intercepted
>>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>>> participating in the VPN. A technique called the Domino-effect
>>>> provisioning of these Label-based Provider Provisioned Lawful
>>>> Intercept mechanism is also outlined.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>
>>
>
>
news:C8AEF564-5BAE-447B-9DBD-41192D1C0407@checkpoint.com
On Jul 22, 2012, at 4:42 AM, Ofer Inbar wrote:
> Glen Zorn <glenzorn@gmail.com> wrote:
>> On Sat, 2012-07-21 at 13:25 -0700, Martin Thomson wrote:
>>
>>> On 21 July 2012 06:55, Yoav Nir <ynir@checkpoint.com> wrote:
>>>> This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
>>>
>>> But moving it to the southern hemisphere would have.
>>
>> How?
>
> By cutting the sunrise-to-sunset fasting period of the day to a much
> shorter period.
That, and although not relevant to Vancouver so much, going without water on a hot summer day is much harder than doing the same on a winter day. It's winter in the southern hemisphere.
Of course, Glen is in Bangkok, so it's hot any day of the year.
Yoav
news:CD5674C3CD99574EBA7432465FC13C1B22726A1DC2@DC-US1MBEX4.global.avaya.com
On Tue, 2012-07-24 at 09:16 -0400, Simon Perreault wrote:
> Even though I replied to the survey, this also irritated me. And I sense
> a trend here. It seems that the number of non-plain-text files coming
> from IAB has been increasing.
>
> Suggestion: just put the content right in the body of the email. I see
> no need for any kind of attachment.
Or the attachment could be text/plain...
Dale
news:1343033779.7688.131.camel@gwz-laptop
On Mon, 2012-07-23 at 10:08 +0200, Henk Uijterwaal wrote:
> On 20/07/2012 18:06, IETF Administrative Director wrote:
> > The IAOC is seeking community feedback on a proposed date change for IETF 95
> > scheduled for March 2016.
> >
> > Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
> >
> > The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> > feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> > by 6 August 2012.
> >
> > Ray Pelletier
> > IETF Administrative Director
>
> If March 27 is Easter, then I'm not sure if the change solves the problem.
> Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as
> well as the Monday after) are religious holidays in many European countries.
>
> If you want to avoid a clash with Easter and related days, then one will
> have to move the meeting to either the week of 13-18 March, or the week of
> 3-8 April.
I agree, and prefer the former.
>
> Henk
>
>
>
news:m21ukr152m.wl%randy@psg.com
> I sincerely thank Matt for his willingness to take on this task
<aol>
and you for when you served.
randy
news:CAA=duU0XK=gJJzS-7gDGP_NQz=dPxvR4G_xRUnPHNoa537YrxQ@mail.gmail.com
As long as you don't go any later than the week of April 10 - the week
of April 17 runs into the start of Passover.
Thanks,
Andy
On Fri, Jul 20, 2012 at 1:29 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>
> On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
>
>> On 7/20/12 09:06 , IETF Administrative Director wrote:
>>> The IAOC is seeking community feedback on a proposed date change for IETF 95
>>> scheduled for March 2016.
>>>
>>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>>>
>>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
>>> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
>>> by 6 August 2012.
>>
>> 20 march is palm sunday on the western calender.
>>
>> If one's a conflict presumably the other is too...
>
> I personally avoid being away from home on Easter, and would prefer that the IETF meeting avoid it.
>
> Yes, Palm Sunday is a question, but not quite on the same scale as Easter. I will note, however, that Good Friday (the Friday before Easter) is a national holiday in a number of countries. People schedule vacations around that weekend.
>
> My suggestion: take the week of April 3 or later.
news:50096DA3.6080800@gmail.com
On 20/07/2012 14:07, IETF Administrative Director wrote:
> The IAOC is seeking community feedback on a proposed policy by the IAOC to impose
> fees to produce information and authenticate documents in response to subpoenas and
> other legal requests.
Do it. This will dissuade trivial requests and will be a drop in the ocean
of costs for serious lawsuits.
Don't forget to appropriately update http://iaoc.ietf.org/subpoena.html.
Brian
news:06CAE00A-F7AF-4D6C-ACE4-0D8399C13F44@sobco.com
I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember)
there were no significant expenses - the depo was in Boston & my only
expense was a few hours parking - the depo was done in the office of the
law firm that was providing the IETF with pro-bono legal services at the time
Scott
On Jul 22, 2012, at 3:58 PM, John R Levine wrote:
>>> For people with unique skills or knowledge, $800/hr is not unusual.
>>> So long as the rate is published ahead of time, you're not going to
>>> get much argument. ("Yes, we know it's high. But we've already told
>>> you how to download stuff yourself for free.")
>>
>> Please note : out of pocket expenses (if someone has to travel to a
>> hearing, say) would be reimbursed, but
>> IETF volunteers will not be paid from these fees.
>
> If you know, how often have people been deposed on behalf of the
> IETF, and how long does it typically take?
>
> My thought is that in a depo or trial, the other side pays both for the expenses and the time of the person being deposed, so it would be good idea to say up front here's what it'll cost if you want a live witness.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
news:500D5C73.4000607@dcrocker.net
On 7/23/2012 4:26 AM, Stephen Farrell wrote:
> I'd encourage you to not try change 2119.
>
> Instead, add whatever new definitions you feel
> you need to your own draft that addresses some
> technical, and not process, topic.
>
> If people find your new definitions useful they'll
> say and if enough of that happens they'll be
> included in a 2119bis whenever that's done.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
news:CD5674C3CD99574EBA7432465FC13C1B22726A0BCA@DC-US1MBEX4.global.avaya.com
> From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
>
> Eran claims that enterprise identity management equipment manufacturer dominate the discussion.
There's a common problem in the IETF that the development of a standard is dominated by companies that incorporate the standard into their products, whereas the people who "really should" be involved in the development are those who will *use* the standard in operation.
Dale
news:4FFC844F.3010207@viagenie.ca
(adding pcp@ietf.org to the recipients list...)
Sam,
Thanks for the review, comments inline...
On 07/10/2012 02:16 PM, Sam Hartman wrote:
> Requirement 9 requires a Port Control Protocol (PCP) server. I think we
> need to say somewhat more about that in order for PCP to be secure on a
> CGN. In this
> discussion I urge people to read section 17.1 (the simple thread model)
> of draft-ietf-pcp-base. We want to be using the simple threat model
> because there's no clear credential that CGN operators are guaranteed to
> share with their customers. If we ask people to set up a credential and
> configure an authentication mechanism to take advantage of the CGN's
> PCP server, people will either ignore our recommendations or CGN PCP will
> be useless.
>
> The cardinal rule of the simple threat model is do no harm: make sure
> that PCP cannot be used in a manner that makes security worse than
> implicit NAT mappings. The CGN situation is a bit more complex than the
> typical simple threat model. I spent this morning going over the CGN
> case with Margaret Wasserman and based on that discussion, I believe the
> following additional requirements are sufficient to use the simple
> threat model for CGNs.
>
> The PCP server MUST NOT permit the lifetime of a mapping to be reduced
> beyond its current life, MUST NOT permit a NAT mapping to be created
> with a lifetime less than the lifetime used for implicit mappings, MUST
> not permit the delete opcode to be used,
Unless I'm mistaken, there is no delete opcode in PCP. You just send a
MAP request with lifetime=0. So I would propose saying:
MUST NOT permit the lifetime of a mapping to be reduced beyond its
current life or be set to zero (deleted)
> and MUST NOT support the third-party option.
I think pcp-base-26 added restrictions to THIRD_PARTY so that it could
be used in CGN scenarios. If that is right, wouldn't it then make sense
to allow THIRD_PARTY on CGNs?
> The map opcode MAY be permitted if the
> recommendation of endpoint independent filtering behavior described in
> REQ-7 is adopted; the map opcode MUST NOT be permitted in other
> circumstances. These constraints MAY be relaxed if a security mechanism
> consistent with PCP's Advanced Threat Model (see Section 17.2 of
> [I-D.ietf-pcp-base]) is used; this is expected to be rare for CGN
> deployments. Mappings created by PCP MUST follow the same deallocation
> behavion (REQ-8) as implicitly mapped traffic.
>
> justification: Most of the concern has to do with one customer device
> interacting negatively with the security of another; this is of
> particular concern when the devices belong to different customers, but
> devices belonging to the same customer are in scope for the PCP security
> analysis as well. Reducing a mapping lifetime or deleting a mapping
> create DOS opportunities and can create an opportunity for one device to
> intercept another device's traffic. If a device spoofs creation of a
> mapping with less than the default lifetime, then that can create DOS or
> packet capture opportunities. The third-party option creates significant
> spoofing opportunities. The behavior of REQ-8 is critical to avoiding
> packet capture attacks.
Thanks for the full requirements text and justification. That going to
make my editing just so much easier!
> My second concern is with section 8.
> This section says that spoofing is a concern of DOS, notes that ingress
> filtering is a defense and makes no recommendation.
>
> I believe spoofing is a significantly greater concern than DOS. As an
> example, I can spoof traffic from you to create an inbound hole towards
> one of your ports.
Is this a new attack vector introduced by CGN? Without NAT, there's no
need for a "hole", anyone can send traffic to any of a subscriber's ports...
Thanks,
Simon
> This is particularly valuable if the filtering
> behavior is endpoint independent as recommended in REQ-7. Spoofing is
> particularly dangerous with PCP if the constraints I listed above are
> not followed. The analysis of the impact of spoofing is a bit tricky,
> because it depends on how spoofing is accomplished and on whether an
> attacker can observe traffic destined for other customers as well. So, I
> think the warning about spoofing needs to be increased.
>
> I also think we need to make a specific recommendation that people
> deploying CGNs deploy sufficient ingress filtering to avoid spoofing. I
> understand this specification is mostly about building CGNs not about
> deploying them. However this issue seems quite important to the security
> of the network.
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:4FF73C46.5090301@att.com
Huh?
Make tao a directory.
Put the document in the directory as index.html.
Now www.ietf.org/tao will redirect to www.ietf.org/tao/ will redirect to
www.ietf.org/tao/index.html.
Tony Hansen
On 7/4/2012 1:54 PM, Russ Housley wrote:
> Julian:
>
>> No, I was just trying to understand *why* the archive can't be at <http://www.ietf.org/tao/archive>.
> I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory.
>
> Russ
news:F5063677821E3B4F81ACFB7905573F2403B95A3E@MX15A.corp.emc.com
I support the change and would not make it there on Easter.
Thank you,
Kathleen
-----Original Message-----
From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF Administrative Director
Sent: Friday, July 20, 2012 12:06 PM
To: IETF Announcement List
Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org
Subject: Proposed IETF 95 Date Change
The IAOC is seeking community feedback on a proposed date change for IETF 95
scheduled for March 2016.
Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
by 6 August 2012.
Ray Pelletier
IETF Administrative Director
news:337C9F850CBEA220D0A03ED3@JcK-HP8200.jck.com
--On Friday, July 06, 2012 07:16 +0200 Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> +1
>
> I support all your suggestions (i.e. point 1 and 2, and nits i
> and ii ) , and hope that iesg, and editor agrees, and that the
> community considers them for progress. I seen the change in the
> draft-document-03 which I think getting better but still not
> satisfied
>
> The new vesion 3 draft (dated 5 July) does not include all your
> suggestion, please read and comment on draft-03 (the subject
> refers to draft-02, did you read draft-03?).
> http://tools.ietf.org/html/draft-hoffman-tao-as-web-page-03
Abdussalam,
Paul's note about draft 03 indicates that he posted it partially
in response to my comments. Those comments were based on 02.
>From my point of view, there is always a question about how much
energy a document like this is worth: it is not normative or
authoritative and, while I'd prefer to see it done differently
(and said so in a follow-up note after skimming -03), I've got
other IETF work to do and would prefer to see Paul and the IESG
working on the Tao text itself rather than fine-tuning this
document.
I personally believe that the document could be further improved
by moving it toward my earlier suggestions. I believe that
more "what is this about" text belong in the Abstract and, in
particular, that the relationship of the Tao (whether as an RFC
or as a web page) deserves more explicit treatment than the
second sentence of the Introduction. And I believe that forcing
another RFC if details of the revision process are changed is a
bad idea and so think that Section 2 (of -03) should talk about
an initial procedure and/or in much more general terms but
should then push details and changes off to the Tao itself
(perhaps as an appendix). Ultimately, if we cannot trust the
IESG and the Editor to be careful and sensible about this
document, we are going to have problems that fine-tuning the RFC
text can't prevent.
But, if Paul and the IESG don't agree, I'm not convinced the
subject justifies a lot more energy.
best,
john
news:4FFAF400.1030201@viagenie.ca
On 2012-07-09 11:03, George, Wes wrote:
> While the NAT specified by this
> document itself may only act on IPv4 traffic, as you note above it's
> not limited to just NAT444 or even an IPv4-only *network*. The
> recommendations in this doc will work for an IPv4 NAT associated with
> DSLite just as easily as a more traditional IPv4 transport. This is
> an important distinction, IMO.
Right, I understand now. It's the logical NAT function that is
IPv4-only, not the global use case. I'll add some text to make this
clear, and I'll specifically point out the DS-Lite example.
>> How about "Common Requirements for IPv4 Carrier Grade NATs
>> (CGNs)"?
> [WEG] This helps, but only in conjunction with additional
> clarification about the application - that is, just because the NAT
> is IPv4-only doesn't mean that the network must also be IPv4-only.
Understood.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:38D14FAE-F086-49CF-B0D2-9F30E1A2A8E7@viagenie.ca
cool!!! I will also be using this! thanks!
Marc.
Le 2012-07-31 à 11:16, Ole Jacobsen a écrit :
>
> In The Internet Protocol Journal I have been using the following
> citation format, best illustrated by an example:
>
> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
> Paths (LSPs)," RFC 6387, September 2011.
>
> So, that's full author names "and" before the last author name, title,
> document number and date, using the American "quotation outside
> punctuation rule."
>
> I got tired of doing this "by hand" so I asked Henrik if he could
> write me a tool. He did (THANKS!), and the result is here:
>
> http://tools.ietf.org/tools/citation/
>
> This will take either the draft name or the RFC number as input and
> produce a citation similar to the one above. You can of course play
> with the elements and generate a format that suits your own taste, for
> example, for I-Ds, in print it might be good to have the FILE NAME as
> the last entry:
>
> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
> Internet Draft, work in progress, July 2011,
> draft-agl-dane-serializechain-01
>
> ...since I like having filenames or URLs on one line (not wrapping)
> as much as possible.
>
> Many thanks again to Henrik, and I hope you will find it useful too!
>
> Ole
>
>
>
> Ole J. Jacobsen
> Editor and Publisher, The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
> Skype: organdemo
news:tsl1ukj9ye1.fsf@mit.edu
>>>>> "Simon" == Simon Perreault <simon.perreault@viagenie.ca> writes:
Simon> MUST NOT permit the lifetime of a mapping to be reduced beyond its
Simon> current life or be set to zero (deleted)
OK.
>> and MUST NOT support the third-party option.
Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it could
Simon> be used in CGN scenarios. If that is right, wouldn't it then make
Simon> sense to allow THIRD_PARTY on CGNs?
I don't think you can describe an subscriber-facing network of an ISP as
"fully trusted."
The text added to 13.1 might permit third_party to be used by an
administrative web service within an ISP but certainly not by customers
of that ISP.
I'd be OK with "MUST NOT allow the third_party option for traffic
recieved from customer-facing interfaces."
or "MUST NOT allow the third_party option in requests received on the
internal network."
Then that still permits the case of third_party for administration
motivating the text in 13.1.
>> My second concern is with section 8.
>> This section says that spoofing is a concern of DOS, notes that ingress
>> filtering is a defense and makes no recommendation.
>>
>> I believe spoofing is a significantly greater concern than DOS. As an
>> example, I can spoof traffic from you to create an inbound hole towards
>> one of your ports.
Simon> Is this a new attack vector introduced by CGN? Without NAT, there's no
Simon> need for a "hole", anyone can send traffic to any of a subscriber's
Simon> ports...
I find it difficult to answer that question. I'd say that it is likely
an unexpected assumption for someone behind a NAT. It is a
vulnerability of CGNs over other NATs, but perhaps not a vulnerability
of CGNs over no NAT or firewall at all.
Why do we care whether it's new? Is it actually bad if we end up
describing a related attack and recommending people deploy in a manner
that avoids it?
news:50186251.7070705@levkowetz.com
Hi Ersue,
On 2012-07-31 13:27 Ersue, Mehmet (NSN - DE/Munich) said the following:
> Nice tool.
>
> However, I am wondering why the tool changes the order of the names.
> There is actually a reason why documents list names in a specific order.
There is no intentional name re-ordering. I'll look into why that happens.
> Some of the citations appear to be incomplete, see RFC3410.
Ok, will check that too.
Thanks for the feedback!
Best regards,
Henrik
> Cheers,
> Mehmet
>
>
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> Of ext Ole
>> Jacobsen
>> Sent: Tuesday, July 31, 2012 11:17 AM
>> To: The IETF
>> Cc: RSOC; Heather Flanagan; rsag@rfc-editor.org
>> Subject: RFC and I-D Citation Tool
>>
>>
>> In The Internet Protocol Journal I have been using the following
>> citation format, best illustrated by an example:
>>
>> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
>> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
>> Paths (LSPs)," RFC 6387, September 2011.
>>
>> So, that's full author names "and" before the last author name, title,
>> document number and date, using the American "quotation outside
>> punctuation rule."
>>
>> I got tired of doing this "by hand" so I asked Henrik if he could
>> write me a tool. He did (THANKS!), and the result is here:
>>
>> http://tools.ietf.org/tools/citation/
>>
>> This will take either the draft name or the RFC number as input and
>> produce a citation similar to the one above. You can of course play
>> with the elements and generate a format that suits your own taste, for
>> example, for I-Ds, in print it might be good to have the FILE NAME as
>> the last entry:
>>
>> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
>> Internet Draft, work in progress, July 2011,
>> draft-agl-dane-serializechain-01
>>
>> ...since I like having filenames or URLs on one line (not wrapping)
>> as much as possible.
>>
>> Many thanks again to Henrik, and I hope you will find it useful too!
>>
>> Ole
>>
>>
>>
>> Ole J. Jacobsen
>> Editor and Publisher, The Internet Protocol Journal
>> Cisco Systems
>> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
>> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
>> Skype: organdemo
>
>
news:alpine.OSX.2.01.1207311421270.87763@173-11-110-132-sfba.hfc.comcastbusiness.net
Mehmet,
The tool is not INTENDED to change the author order. A somewhat
incomplete database can indeed lead to unexpected results, use with
caution.
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 Mobile: +1 415-370-4628
E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
Skype: organdemo
On Tue, 31 Jul 2012, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Nice tool.
>
> However, I am wondering why the tool changes the order of the names.
> There is actually a reason why documents list names in a specific order.
>
> Some of the citations appear to be incomplete, see RFC3410.
>
> Cheers,
> Mehmet
>
>
> > -----Original Message-----
> > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> Of ext Ole
> > Jacobsen
> > Sent: Tuesday, July 31, 2012 11:17 AM
> > To: The IETF
> > Cc: RSOC; Heather Flanagan; rsag@rfc-editor.org
> > Subject: RFC and I-D Citation Tool
> >
> >
> > In The Internet Protocol Journal I have been using the following
> > citation format, best illustrated by an example:
> >
> > Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
> > Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
> > Paths (LSPs)," RFC 6387, September 2011.
> >
> > So, that's full author names "and" before the last author name, title,
> > document number and date, using the American "quotation outside
> > punctuation rule."
> >
> > I got tired of doing this "by hand" so I asked Henrik if he could
> > write me a tool. He did (THANKS!), and the result is here:
> >
> > http://tools.ietf.org/tools/citation/
> >
> > This will take either the draft name or the RFC number as input and
> > produce a citation similar to the one above. You can of course play
> > with the elements and generate a format that suits your own taste, for
> > example, for I-Ds, in print it might be good to have the FILE NAME as
> > the last entry:
> >
> > Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
> > Internet Draft, work in progress, July 2011,
> > draft-agl-dane-serializechain-01
> >
> > ...since I like having filenames or URLs on one line (not wrapping)
> > as much as possible.
> >
> > Many thanks again to Henrik, and I hope you will find it useful too!
> >
> > Ole
> >
> >
> >
> > Ole J. Jacobsen
> > Editor and Publisher, The Internet Protocol Journal
> > Cisco Systems
> > Tel: +1 408-527-8972 Mobile: +1 415-370-4628
> > E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
> > Skype: organdemo
>
>
news:CAC8QAce9Gd8GkViAfukZQSQXfOm5tZsXgDTkRt_PDNOAGUSG0Q@mail.gmail.com
I don't understand why this issue is coming up.
Maybe you don't know, IETF 84 falls in the month of Ramadan for
Muslims and nobody asked to change it?
My 2 cents.
Behcet
On Fri, Jul 20, 2012 at 11:06 AM, IETF Administrative Director
<iad@ietf.org> wrote:
> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
news:CAMm+LwjGoHMU_NGFJW9q_HEgn+NzVRGPx+eukN6u3-ZCrrmcWA@mail.gmail.com
There must be a cheaper way for NBC commentators to work out who Sir Tim
Berners-Lee is.
Perhaps we should have someone give an innane commentary...
On Tuesday, July 24, 2012, IETF Administrative Director wrote:
> The IAOC is pleased to announce the Co-Hosts for IETF 86 in Orlando
> Florida, USA
> March 10 - 15, 2013.
>
> The Co-Hosts are Comcast and NBCUniversal. Comcast Hosted IETF 71 in
> Philadelphia, is
> sponsoring IETF 85 in Atlanta, and has sponsored meeting breaks and ice
> cream socials at
> other meetings. <http://www.comcast.com>
>
> NBCUniversal is Hosting its first meeting with the IETF. <
> http://www.nbcuni.com/>
>
> We want to thank our benefactors. The IETF cannot support its technical
> standards efforts,
> including the Secretariat and RFC Editor, without the generous support of
> its hosts and
> sponsors.
>
> Interested in hosting or sponsoring an IETF meeting? Contact Drew
> Dvorshak at
> dvorshak@isoc.org <javascript:;>. The meeting schedule is here: <
> https://www.ietf.org/meeting/
> upcoming.html>
>
> Thanks again to Comcast and NBCUniversal!
>
> We are just days away from IETF 84 in Vancouver. Registrations are open
> and operators
> are standing by (so to speak). Visit <
> https://www.ietf.org/meeting/84/index.html> and join
> the 1,250 who have already registered.
>
> Ray Pelletier
> IETF Administrative Director
>
--
Website: http://hallambaker.com/
news:CD5674C3CD99574EBA7432465FC13C1B22726A1D8C@DC-US1MBEX4.global.avaya.com
On Fri, 2012-07-20 at 06:07 -0700, IETF Administrative Director wrote:
> The draft policy entitled Draft Fee Policy for Legal Requests can be found
> at: <http://iaoc.ietf.org/policyandprocedures.html>
Assuming that the IAOC has set these fees to be close to the actual
costs of servicing legal requests, I see no objection to the policy.
Dale
news:m2r4rtw8bw.wl%randy@psg.com
> Under the long-standing IETF policy defined in RFC 2804, I trust
> we will not be discussing this draft, or
> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
<aol>
news:009701cd68dd$06642560$132c7020$@us
+1 Excellent idea in principle ..IMHO just a matter of working out details.
-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Bradner, Scott
Sent: Friday, July 20, 2012 10:17 AM
To: Scott Brim
Cc: wgchairs@ietf.org; ietf@ietf.org; iaoc@ietf.org; iab@iab.org; IETF
Announcement List
Subject: Re: Feedback Requested on Draft Fees Policy
great idea - just does not jive with the legal system which often need
authenticated copies of documents
Scott
On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
> > On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
> >> The draft policy entitled Draft Fee Policy for Legal Requests can
> >> be found
> >> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Fine idea.
news:500654AB.7060500@necom830.hpcl.titech.ac.jp
Joe Touch wrote:
>> Or, are 6 to 4 translators are required to rate limit and
>> drop rate-violating packets to make the "stateless"
>> translators full of states.
>
> I would expect that the translator would be responsible
> for this, though
Do you mean translators must rate limit, or translators
violate RFC2765:
>> Identification:
>> Copied from the low-order 16-bits in the
>> Identification field in the Fragment header.
and use some other number as an ID?
> there is the problem that multiple translators interfere
> with each other.
Yes, even rate limiting translators may interfere each other,
which means rate limiting must be done at the IPv6 source
node.
> Regardless, this is outside the scope of the ipv4-id-update doc.
In the ID, there are a lot of references to IPv6.
For example, the following statement of the ID:
Finally, the IPv6 ID field is
32 bits, and required unique per source/destination address pair for
IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
must be modified as:
Finally, the IPv6 ID field is
32 bits, but lower 16 bits are required unique per
source/destination address pair for
IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
Masataka Ohta
news:2D34DBB5-543F-47A3-A649-BDDFF76A6438@netapp.com
On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
> I found it is to be odd to have a requirements document as a BCP, but I am sure
> you can sort the right status out with IESG.
+1
I fail to see why Informational wouldn't be the better status.
Lars
news:20120711.053654.193724485.miyakawa@nttv6.jp
>> Then that still permits the case of third_party for administration
>> motivating the text in 13.1.
>
> Makes sense to me.
+1
> How about adding a sentence like...
>
> "CGN as described in this document does not provide any security
> benefits over either single-user NAT or no NAT at all."
I agree with Simon (also as one of the authors of this draft).
We think that CGN is not the machine to proveide security benefits
and the original intension of this draft is just to make CGN as neutral as possible...
Best wishes,
Shin Miyakawa
news:45AB8A7A-0DF1-4FA0-AB90-1485F90F52AD@frobbit.se
27 jul 2012 kl. 23:42 skrev Paul Hoffman <paul.hoffman@vpnc.org>:
>> I miss RL "Bob" Morgan. I am sure many others in the IETF community do as well.
>
> For those of you whom are only now finding out about Bob's death, here's a bit of background:
There is an article in the latest version of IETF Journal where he plays an important part, including photo of him.
http://www.internetsociety.org/articles/implementing-identity-management-solutions
I am happy to see the addition to the article online that of course does not exist in the printed version.
Patrik
news:EDC652A26FB23C4EB6384A4584434A0407E24097@307622ANEX5.global.avaya.com
(I hope not to open some Pandora box or a long thread - my goal is to
make sure there is clarity in the language of the statement)
What 'IETF protocol specification' means here?
Pretty clear it covers protocols defined in IETF standards-track
documents.
Does it also cover protocols defined (described) in Informational RFCs
which are part of the IETF stream?
Dan
> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> bounces@ietf.org] On Behalf Of IETF Chair
> Sent: Monday, July 30, 2012 7:40 PM
> To: IETF Announce
> Cc: IETF
> Subject: Draft IESG Statement Regarding Ethertype Requests
>
> Last week the IAB and the IESG met with the leadership of IEEE 802.
One
> of the things that was discussed was the IEEE policies for allocating
> EtherTypes, and the IESG is considering the attached IESG Statement to
> implement an IETF policy that aligns with the IEEE policy.
>
> If you have an comments on this proposed policy, please raise them on
> ietf@ietf.org.
>
> Russ
>
> = = = = = =
>
> The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
> (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF
> protocol specification make use of Ethertypes. Since Ethertypes are a
> fairly scarce resource, the IEEE RAC will not assign an Ethertype to a
> new IETF protocol specification that needs a new Ethertype until the
> IESG has approved the specification for publication as an RFC.
>
> To let the IEEE RAC know that the IESG has approved an IETF protocol
> specification for publication, all future requests for assignment of
> Ethertypes for IETF protocol specifications will be made by the IESG.
>
> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for
use
> during development and experimentation.
>
>
> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
> IEEE standard for Local and Metropolitan Area Networks:
> Overview and Architecture -- Amendment 1: Ethertypes for
> Prototype and Vendor-Specific Protocol Development.
news:9EF2836F-B9C6-47BF-AAE9-87DE15574E95@tzi.org
On Jul 22, 2012, at 21:38, Marshall Eubanks wrote:
> IETF volunteers will not be paid from these fees.
I've been following this discussion only with one ear, but, I can't figure out why somebody would volunteer to do this.
Grüße, Carsten
news:alpine.BSF.2.00.1207230205230.12609@fledge.watson.org
No objection. Thank you for asking.
Just as with any project that you don't really want to take on, make
sure the price is high enough that you're willing to do it should
someone be foolish enough to pay the asking price.
Also consider adding an automatic fee escalation clause (e.g. permit
the IAD to raise the fee by up to 5% per year without further IAOC
action).
-- Sam
news:4FF66982.70308@att.com
Authoritative, no. But definitely referenced by many, many people and
IMO worthy of a certain amount of care.
Tony Hansen
On 7/5/2012 11:57 PM, John C Klensin wrote:
> --On Thursday, July 05, 2012 23:22 -0400 Tony Hansen
> <tony@att.com> wrote:
>
>> I think my point was missed. Section 2 says:
>>
>> All published versions will be archived using URLs of the form
>> <http://www.ietf.org/tao-YYYYMMDD.html>.
>>
>> My question is: Where is there a list of all of the tao
>> version files? How would one be able to find out the name of
>> the previous version so they could do a diff and see what has
>> changed? How can I see a history of the files?
>> ...
> Tony,
>
> Mostly out of curiosity, why do you think it is important. If
> the Tao were a reference document that was authoritative on IETF
> procedures or the like, it would be a different matter: I can
> think of many reasons why it might be important to establish
> exactly what the rules and procedures were at any given time.
> But, given that it is a non-authoritative tutorial summary
> description of how we do things, I have a certain amount of
> trouble understanding why going to extra effort to maintain a
> long-term back trace is actually important.
>
> What am I missing?
>
> john
>
news:500D03C9.9030305@gmx.de
On 2012-07-23 00:33, Stephen Farrell wrote:
>
> Hi all,
>
> I'd like to check that some recent minor changes to this
> document [1] don't cause technical or process-grief.
>
> The version [2] of the oauth bearer draft that underwent
> IETF LC and IESG evaluation had a normative dependency
> on the httpbis wg's authentication framework. [3]
>
> After resolving IESG discuss positions the authors and
> wg chairs felt that it would be better to replace the
> normative reference to the httpbis wg draft [3] with one
> to RFC 2617 [4] so that the OAuth drafts wouldn't be held
> in the RFC editor queue waiting on the httpbis wg to get
> done.
>
> I believe there is no impact on interop resulting from
> this change but there has been some disagreement about
> making it and how it was made. After some offlist discussion
> I think we now have an RFC editor note [5] that means that
> the current scheme of referring to RFC 2617 is ok.
> ...
Quoting:
> NEW:
>
> The "Authorization" header for this scheme follows the usage
> of the Basic scheme [RFC2617]. Note that, as with Basic, this
> is compatible with the the general authentication framework
> being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though
> does not follow the preferred practice outlined therein in
> order to reflect existing deployments. The syntax for Bearer
> credentials is as follows:
That helps, but it still hides the fact that the syntax is not
compatible with the RFC 2617 framework.
Also, s/header/header field/
Proposal:
"The syntax of the "Authorization" header field for this scheme follows
the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note
that, as with Basic, it does not conform to the generic syntax defined
in Section 1.2 of [RFC2617], but that it is compatible with the the
general authentication framework being developed for HTTP 1.1
[I-D.ietf-httpbis-p7-auth], although it does not follow the preferred
practice outlined therein in order to reflect existing deployments.
The syntax for Bearer credentials is as follows: ..."
Best regards, Julian
news:500C29D1.7070605@gmail.com
On 7/22/12 3:17 AM, Abdussalam Baryun wrote:
> IF x, THEN y:
>
> ELSE:
>
> ELSE IF:
>
> Please send your comments or advise, thanking you,
Yes: you might try to explain what problem you think you're
solving.
Melinda
news:9DF09405CDDF0E625FA03977@JcK-HP8200.jck.com
--On Thursday, July 05, 2012 23:22 -0400 Tony Hansen
<tony@att.com> wrote:
> I think my point was missed. Section 2 says:
>
> All published versions will be archived using URLs of the form
> <http://www.ietf.org/tao-YYYYMMDD.html>.
>
> My question is: Where is there a list of all of the tao
> version files? How would one be able to find out the name of
> the previous version so they could do a diff and see what has
> changed? How can I see a history of the files?
>...
Tony,
Mostly out of curiosity, why do you think it is important. If
the Tao were a reference document that was authoritative on IETF
procedures or the like, it would be a different matter: I can
think of many reasons why it might be important to establish
exactly what the rules and procedures were at any given time.
But, given that it is a non-authoritative tutorial summary
description of how we do things, I have a certain amount of
trouble understanding why going to extra effort to maintain a
long-term back trace is actually important.
What am I missing?
john
news:80A0822C5E9A4440A5117C2F4CD36A6404136619@DEMUEXC006.nsn-intra.net
Nice tool.
However, I am wondering why the tool changes the order of the names.
There is actually a reason why documents list names in a specific order.
Some of the citations appear to be incomplete, see RFC3410.
Cheers,
Mehmet
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
Of ext Ole
> Jacobsen
> Sent: Tuesday, July 31, 2012 11:17 AM
> To: The IETF
> Cc: RSOC; Heather Flanagan; rsag@rfc-editor.org
> Subject: RFC and I-D Citation Tool
>
>
> In The Internet Protocol Journal I have been using the following
> citation format, best illustrated by an example:
>
> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
> Paths (LSPs)," RFC 6387, September 2011.
>
> So, that's full author names "and" before the last author name, title,
> document number and date, using the American "quotation outside
> punctuation rule."
>
> I got tired of doing this "by hand" so I asked Henrik if he could
> write me a tool. He did (THANKS!), and the result is here:
>
> http://tools.ietf.org/tools/citation/
>
> This will take either the draft name or the RFC number as input and
> produce a citation similar to the one above. You can of course play
> with the elements and generate a format that suits your own taste, for
> example, for I-Ds, in print it might be good to have the FILE NAME as
> the last entry:
>
> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
> Internet Draft, work in progress, July 2011,
> draft-agl-dane-serializechain-01
>
> ...since I like having filenames or URLs on one line (not wrapping)
> as much as possible.
>
> Many thanks again to Henrik, and I hope you will find it useful too!
>
> Ole
>
>
>
> Ole J. Jacobsen
> Editor and Publisher, The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
> Skype: organdemo
news:1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com
There are few things that in my opinion should be added.
First, the port numbers to be allocated to CPE. Excluding Well known port numbers should be mentioned. Moreover if port numbers are allocated to each CPE, what is the criteria for allocation. As mentioned in the document : “ There should be no limit on the size of the address pool”, does this address pool imply the one that would be allocated to the CPE? According to the requirement of the CPE, the pool should be allocated or a fixed number of addresses in the address pool should be allocated to each CPE? Some amount of clarity in this respect would be helpful.
Moreover, the document advocates the use of Endpoint independent filtering. If AID is used, there would be a delay of 120 seconds for each port reallocation. So should EIF be used only with those applications that can’t function without it, instead of applying it for all.
The need to maintain a record or database of the allocated ports and their lifetime would be helpful. If this is maintained, the ports that are near to expiring their lifetime would be considered first and allocated before and in a order. In such cases there will be less chances of the traffic being dropped due to ports not being available. There should be a definite lifetime defined, before connection is refused due to unavailability of ports. If there is a threshold of say,180 seconds, during which allocated ports database can be scanned and if any ports is recently available, can be allocated. This would lead to efficient use of ports.
Tina
On Jul 9, 2012, at 8:08 AM, "Simon Perreault" <simon.perreault@viagenie.ca<mailto:simon.perreault@viagenie.ca>> wrote:
On 2012-07-09 11:03, George, Wes wrote:
While the NAT specified by this
document itself may only act on IPv4 traffic, as you note above it's
not limited to just NAT444 or even an IPv4-only *network*. The
recommendations in this doc will work for an IPv4 NAT associated with
DSLite just as easily as a more traditional IPv4 transport. This is
an important distinction, IMO.
Right, I understand now. It's the logical NAT function that is IPv4-only, not the global use case. I'll add some text to make this clear, and I'll specifically point out the DS-Lite example.
How about "Common Requirements for IPv4 Carrier Grade NATs
(CGNs)"?
[WEG] This helps, but only in conjunction with additional
clarification about the application - that is, just because the NAT
is IPv4-only doesn't mean that the network must also be IPv4-only.
Understood.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
sunset4@ietf.org<mailto:sunset4@ietf.org>
https://www.ietf.org/mailman/listinfo/sunset4
news:72D7767E-8AE5-4A91-BE2C-4A949997C5CA@vigilsec.com
Peter:
Thanks for the review. I've not read this document yet, but you review raises a question in my mind.
If a DNSSEC policy or practice statement is revised or amended, what actions are needed make other aware of the change?
Russ
On Jul 14, 2012, at 9:01 PM, Peter Yee wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> This draft is ready for publication as an Informational RFC.
>
> Document: draft-ietf-dnsop-dnssec-dps-framework-08
> Reviewer: Peter Yee
> Review Date: 14-July-2012
> IETF LC End Date: 17-July-2012
> IESG Telechat date: Pending
>
> Summary: This draft provides a framework for the creation of DNSSEC Policies
> and Practice Statements.
>
> Major Issues: None
>
> Minor Issues:
>
> Section 4.4.5 discusses how to handle key compromise. It might be useful to
> discuss here or somewhere else in the document how the compromise is
> prevented from recurring if there were no attenuating measures in place
> beforehand. That might well lead to a revision of the DP or DPS. The draft
> doesn't really discuss under what circumstances a document should be
> iterated or amended. Of course, that might be considered a meta issue
> and outside of the scope of the DP or DPS proper.
>
> Nits/editorial comments:
>
> In Section 4.6, "behaviour" is spelt in the British manner. While
> most assuredly not incorrect, you may wish to spell it in the
> American manner.
>
> Serial commas are used inconsistently. Nothing as egregious as the
> following
> example, however. ;-)
> http://grammarnowtips.wordpress.com/2011/01/08/a-case-for-the-serial-comma/
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
news:5005B58F.40608@qualcomm.com
On 7/3/12 7:51 AM, Eggert, Lars wrote:
> On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
>
>> I found it is to be odd to have a requirements document as a BCP, but I am sure
>> you can sort the right status out with IESG.
>>
> +1
>
> I fail to see why Informational wouldn't be the better status.
>
> Lars
Publicly reposting what I just put in my IESG ballot, just in case you
all want to disagree with me publicly. :-)
Perhaps I'm just being contrarian today, but I *do* think this document
should be BCP and not Informational. It is not a requirements document
in the sense that it is laying out requirements for future protocol
documents being developed by a WG; it is a consensus document listing
the requirements for the operation and administration of a type of
device. If that doesn't fall within the 2nd paragraph of RFC 2026
section 5, I don't know what does.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
news:62148A5F-B5F0-4915-8064-F33A0ADCB311@cdt.org
On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote:
>> The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.
>
> See my answer to SM. I think it better explains that the expectations
> of the end user are important to consider, even if these expectations
> are wrong.
Right, I'm not saying that user expectations are unimportant. I think characterizing their role accurately should be the goal. If there is a desire to leave this in, I would suggest something more along the lines of:
Proxies using this extension will preserve the information of a direct connection. In some cases, the user's and/or deployer's knowledge or expectation that this will occur can help to mitigate the associated privacy impact.
>
> I don't think that text will have much impact on how the header field
> is used in practice though, or any technical impact, so removing it is
> fine with me.
Even if that's the case having accurate documentation of the privacy implications can't hurt.
Alissa
>
> It would be interesting to hear what Stephen Farrell thinks about it,
> since he wrote that text.
>
>
> Cheers,
> Andreas
news:alpine.OSX.2.01.1207221021190.83495@173-11-110-132-sfba.hfc.comcastbusiness.net
I think you should look into the possibility. January maybe, or
February, give our attendees some sense of what "cold and dark"
really means :-) Much more productive when you can't leave the
building...
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 Mobile: +1 415-370-4628
E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
Skype: organdemo
On Sun, 22 Jul 2012, Melinda Shore wrote:
> On 7/22/12 8:04 AM, John Levine wrote:
> > You're not going to find cool temperatures again in July or August
> > unless you go as far south as Argentina or New Zealand.
>
> Not only is there life north of the 60th parallel (N), there are
> even hotels and restaurants and airports. Anchorage is probably
> large enough for an IETF meeting, although trying to hold a meeting
> there during tourist season would almost certainly be a mistake.
> But still.
>
> Melinda
>
>
>
news:20120711154158.60f6ecf0@hetzer
On Tue, 10 Jul 2012 08:43:43 -0700
SM <sm@resistor.net> wrote:
>>> In Section 6.3:
>>>
>>> 'To distinguish the obfuscated identifier from other identifiers,
>>> it MUST have a leading underscore "_".'
>>>
>>> I suggest removing the requirement and using "can". The implementer
>>> can decide what to put in that field.
>At 04:28 10-07-2012, Andreas Petersson wrote:
>>I think that will make parsing harder, and give no benefit at all.
>
> It allows for more random bits of information.
>
(adding context again)
Hi,
Can you substantiate a bit on this statement?
How is it "random bits of information" when the specifications says
that it MUST be underscore?
As far as I can think of, the only thing that it will tell is that the
implementation is following this specification.
So, on the contrary; the more "degrees of freedom" that is given to the
implementation, the easier it would be to do fingerprinting.
Cheers,
Andreas
news:11358423-A51A-4353-A883-C5BFA2BF13BC@vpnc.org
On Jul 27, 2012, at 2:28 PM, IETF Chair wrote:
> The memorial service for RL "Bob" Morgan will take place on Sunday. Since many of his friends will be in Vancouver for the IETF meeting, we have arranged a room at the Hyatt hotel to receive the broadcast from the the memorial as it takes place in Seattle. If you want to participate, please come to Regency F from 11:00AM - 2:00PM on Sunday.
>
> I miss RL "Bob" Morgan. I am sure many others in the IETF community do as well.
For those of you whom are only now finding out about Bob's death, here's a bit of background:
On Jul 26, 2012, at 3:06 PM, Michael R. Gettes wrote:
> The tribute web site has been updated with information about the Memorial for Bob to
> be held this Sunday @ 11 AM Pacific Time, 2PM Eastern, 7PM London and 4AM Monday in Sydney.
>
> Please visit https://spaces.internet2.edu/display/rlbob/Home for more information.
>
> The event will be broadcast video with an accompanying twitter feed.
>
> Please consider a donation to the education of Bob's children or to a charity in his name.
> Information about donating can be found on his tribute web site.
>
> Please feel free to forward this email as you see fit to ensure everyone is aware of the event.
news:8D602BA3-CF79-4A3B-BDAD-3F0B6461075F@kumari.net
On Jul 14, 2012, at 3:18 PM, Christian Huitema wrote:
> Very useful document, certainly worth publishing.
+1
> It is one of those documents that needs frequent updates.
>
+1
> RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators, makes reference to a predecessor of this document, stating in section 3.1 that "The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]." I assume that implementers will automatically upgrade their code to reference the new version.
>
-1 -- I would not assume any such thing. I *might* guess that implementors will include the new version in new / updated code, but the not necessarily the "automatically" bit :-P
W
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Randy Bush
> Sent: Friday, July 13, 2012 4:21 PM
> To: IETF Disgust; The IESG
> Subject: [IETF] Re: Last Call: <draft-vegoda-cotton-rfc5735bis-02.txt> (Special Use IPv4 Addresses) to Best Current Practice
>
>> The IESG has received a request from an individual submitter to
>> consider the following document:
>> - 'Special Use IPv4 Addresses'
>> <draft-vegoda-cotton-rfc5735bis-02.txt> as Best Current Practice
>
> read and support
>
> randy
>
>
--
"Working the ICANN process is like being nibbled to death by ducks,
it takes forever, it doesn't make sense, and in the end we're still dead in the water."
-- Tom Galvin, VeriSign's vice president for government relations.
news:F404FCF4-3E55-4F5B-A17C-B6D85C84824C@vpnc.org
Based on many people's input (most recently, John's), I have updated the draft to more cleanly separate out the history of the Tao from the change that is happening.
--Paul Hoffman
A new version of I-D, draft-hoffman-tao-as-web-page-03.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.
Filename: draft-hoffman-tao-as-web-page
Revision: 03
Title: Publishing the "Tao of the IETF" as a Web Page
Creation date: 2012-07-05
WG ID: Individual Submission
Number of pages: 3
URL: http://www.ietf.org/internet-drafts/draft-hoffman-tao-as-web-page-03.txt
Status: http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page
Htmlized: http://tools.ietf.org/html/draft-hoffman-tao-as-web-page-03
Diff: http://tools.ietf.org/rfcdiff?url2=draft-hoffman-tao-as-web-page-03
Abstract:
This document describes how the "Tao of the IETF", which has been
published as a series of RFCs in the past, will instead be published
as a web page.
news:50188662.6000809@levkowetz.com
Hi Ole,
On 2012-07-31 16:17 Ole Jacobsen said the following:
>
> One feature request that I discussed with Henrik was to either
> "auto-detect" I-D file names and handle them slightly differently
> from RFC numbers (by putting the file name as the final entry)
> OR just having two tools. With the kind of feedback Henrik is
> getting I am sure the tool will be improved/enhanced over time.
I'm thinking about how to do this best now. One option I'm considering
is to provide two template fields in the tool, one to be used for
references to RFCs, the other to references to drafts.
Best regards,
Henrik
news:alpine.LRH.2.01.1207221359180.5034@egate.xpasc.com
Yeah, with what the lawyers in the room are getting per hour, there is no
reason to volunteer as an expert wittness. Ever. Even if you are there
on behalf of the IETF, if the IETF prevails, they can only recover costs
they incurred and if they don't, make a donation.
On Sun, 22 Jul 2012, John R Levine wrote:
> > I did not do them any favor - I did the IETF a favor (as the then ISOC VP
> > for Standards)
>
> Really, if you didn't make the opposing party pay for your time, you did them
> a favor. It's absolutely expected to pay hostile witnesses for their depo
> time. (If nobody mentioned it, why would they offer to pay if you were willing
> to do it for free?)
>
> If it happens again, pick the highest rate you think you're worth and double
> it. If you want, donate the money to the IETF trust and encourage them to use
> it for better cookies.
>
> R's,
> John
>
news:4FF4684F.9030603@gmx.de
On 2012-07-04 16:52, Russ Housley wrote:
> Julian:
>
> Do you object to http://www.ietf.org/tao-archive for the old version of the Tao?
>
> Russ
No, I was just trying to understand *why* the archive can't be at
<http://www.ietf.org/tao/archive>.
Best regards, Julian
news:29BF6AF1-3924-42F0-B8BD-1B1250CAECD6@hopcount.ca
Hi Russ,
On 2012-07-15, at 11:39, Russ Housley wrote:
> Peter:
>
> Thanks for the review. I've not read this document yet, but you review raises a question in my mind.
>
> If a DNSSEC policy or practice statement is revised or amended, what actions are needed make other aware of the change?
Each DPS contains these kinds of details. Guidance for how to write the corresponding DPS sections is included in this draft:
4.2. Publication and repositories
The component describes the requirements for an entity to publish
information regarding its practices, public keys, the current status
of such keys together with details relating to the repositories in
which the information is held. This may include the responsibilities
of publishing the DPS and of identifying documents that are not made
publicly available owing to their sensitive nature, e.g. security
controls, clearance procedures, or business information.
4.2.1. Repositories
This subcomponent describes the repository mechanisms used for making
information available to the stakeholders, and may include:
o The locations of the repositories and the means by which they may
be accessed;
o An identification of the entity or entities that operate
repositories, such as a zone operator or a TLD Manager;
o Access control on published information objects.
o Any notification services which may be subscribed to by the
stakeholders;
Joe
news:500D369B.2070603@cs.tcd.ie
Hiya,
On 07/23/2012 08:56 AM, Julian Reschke wrote:
> On 2012-07-23 00:33, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> I'd like to check that some recent minor changes to this
>> document [1] don't cause technical or process-grief.
>>
>> The version [2] of the oauth bearer draft that underwent
>> IETF LC and IESG evaluation had a normative dependency
>> on the httpbis wg's authentication framework. [3]
>>
>> After resolving IESG discuss positions the authors and
>> wg chairs felt that it would be better to replace the
>> normative reference to the httpbis wg draft [3] with one
>> to RFC 2617 [4] so that the OAuth drafts wouldn't be held
>> in the RFC editor queue waiting on the httpbis wg to get
>> done.
>>
>> I believe there is no impact on interop resulting from
>> this change but there has been some disagreement about
>> making it and how it was made. After some offlist discussion
>> I think we now have an RFC editor note [5] that means that
>> the current scheme of referring to RFC 2617 is ok.
>> ...
>
> Quoting:
>
>> NEW:
>>
>> The "Authorization" header for this scheme follows the usage
>> of the Basic scheme [RFC2617]. Note that, as with Basic, this
>> is compatible with the the general authentication framework
>> being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though
>> does not follow the preferred practice outlined therein in
>> order to reflect existing deployments. The syntax for Bearer
>> credentials is as follows:
>
> That helps, but it still hides the fact that the syntax is not
> compatible with the RFC 2617 framework.
"hides" isn't a goal:-)
> Also, s/header/header field/
>
> Proposal:
>
> "The syntax of the "Authorization" header field for this scheme follows
> the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note
> that, as with Basic, it does not conform to the generic syntax defined
> in Section 1.2 of [RFC2617], but that it is compatible with the the
> general authentication framework being developed for HTTP 1.1
> [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred
> practice outlined therein in order to reflect existing deployments.
>
> The syntax for Bearer credentials is as follows: ..."
That looks better. I've updated the RFC editor note to
use your text.
Thanks,
S.
>
> Best regards, Julian
>
>
>
>
news:F47AEC1A-E11F-45C2-9371-61B4A52FBA9D@gmail.com
Richard,
On Jul 20, 2012, at 9:40 AM, Richard L. Barnes wrote:
>
> On Jul 20, 2012, at 11:56 AM, Dave Crocker wrote:
>
>> On 7/20/2012 7:25 AM, Richard L. Barnes wrote:
>>> We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
>>
>>
>> Do you know that these are acceptable to most/all courts?
>>
>> d/
>
>
> IANAL, so no. But what else are we going to provide that's better?
>
We are doing things like signing internet-drafts and RFCs to make this possible, but it will be a long while before the courts catch up. They are not exactly early adopters of things like this :-)
Bob
news:500539A1.9060200@isode.com
Hi Simon,
On 10/07/2012 18:50, Simon Perreault wrote:
> On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
>> I found the justification for REQ-6 hard to read/understand. Why does
>> access to
>> servers being on the internal network need to go through CGN at all?
>
> Here's the thing: the server is not on the internal network. It's on
> the external network, but it is still managed by the ISP. The ISP's
> network includes the internal network and some part of the external
> network. Furthermore, in many cases an ISP may run multiple CGNs, so
> the ISP's network is actually multiple internal networks and some part
> of the external network. The servers in the external network are
> operated by the ISP and "know" the internal networks (have routes to
> them), and can reach them directly without translation. And since
> connections from subscribers to those servers may account for a lot of
> traffic, it is important to not spend NAT resources on them.
I like this longer explanation. I agree that once I understand what you
are trying to say the shorter explanation in the document makes sense.
But it is a bit cryptic. (I don't have specific suggestions, so if you
can't improve existing text, that is Ok with me.)
> Now, I'm not sure how to alter the existing text to make it easier to
> understand. It seems to me that all the information is there, just not
> with the same order/emphasis as what I wrote above. If the above was
> useful for you to understand, could you please point out in the text
> below what change would have helped you understand?
>
> REQ-6: It MUST be possible to administratively turn off translation
> for specific destination addresses and/or ports.
>
> Justification: It is common for a CGN administrator to provide
> access for subscribers to servers installed in the ISP's network,
> in the external realm. When such a server is able to reach the
> internal realm via normal routing (which is entirely controlled by
> the ISP), translation is unneeded. In that case, the CGN may
> forward packets without modification, thus acting like a plain
> router. This may represent an important efficiency gain.
>
> Figure 2 illustrates this use-case.
>
>
> X1:x1 X1':x1' X2:x2
> +---+from X1:x1 +---+from X1:x1 +---+
> | C | to X2:x2 | | to X2:x2 | S |
> | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
> | i | | G | | r |
> | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
> | n |from X2:x2 | |from X2:x2 | e |
> | t | to X1:x1 | | to X1:x1 | r |
> +---+ +---+ +---+
>
> Figure 2: CGN pass-through
>
> Thanks,
> Simon
news:2A096686-53B2-42C0-8A7B-CEDD691AB2AD@gmx.net
Hi Yoav,
>
> Hi
>
> Like Dale, I haven't followed the play throughout the life of OAuth (the working group)
>
Barely anyone has done that.
> Who are these corporations that dominate the working group? Are they content providers like Facebook, Twitter, or Disney? Are they ISPs? Is it General Motors?
Eran claims that enterprise identity management equipment manufacturer dominate the discussion.
>
> If they are the people who are supposed to use these standards, their participation is a good thing.
Getting everyone who writes Web applications involved in the standards process is "a bit difficult".
If you look at the mailing list you see a mixture of small and big companies involved.
> I wish we had more users (corporate or others) in the Security Area. So who are they?
The OAuth group is more a consumer of security expertise rather than the source.
Ciao
Hannes
>
> Yoav
news:20120711164111.1b9e86d5@hetzer
On Tue, 10 Jul 2012 12:32:08 -0400
Alissa Cooper <acooper@cdt.org> wrote:
> On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote:
> >> The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.
> >
> > See my answer to SM. I think it better explains that the expectations
> > of the end user are important to consider, even if these expectations
> > are wrong.
>
> Right, I'm not saying that user expectations are unimportant. I think characterizing their role accurately should be the goal. If there is a desire to leave this in, I would suggest something more along the lines of:
>
> Proxies using this extension will preserve the information of a direct connection. In some cases, the user's and/or deployer's knowledge or expectation that this will occur can help to mitigate the associated privacy impact.
Off-list discussion with Alissa resulted in this suggestion:
"Proxies using this extension will preserve the information of a direct
connection. This has an end-user privacy impact regardless of whether
the end-user or deployer knows or expects that this is the case."
Cheers,
Andreas
news:20120710132756.4dac582d@hetzer
On Mon, 9 Jul 2012 14:27:49 -0400
Alissa Cooper <acooper@cdt.org> wrote:
> (incorporating some responses to http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html as a LC comment)
>
> It would be helpful if this document could further motivate the need for proxies to generate static obfuscated tokens. These two lines in particular, from 6.3 and 8.3, respectively, seem a bit weak:
>
> "The identifiers can
> be randomly generated for each request and do not need to be
> statically assigned to resources."
>
> "When using such tokens, a static token per user would increase the
> possibility for external organizations to track separate users."
Well, I think it gives a good hint to use dynamically assigned tokens.
> Is it possible to recommend that generated tokens have limited lifetimes (per-request or otherwise), and make the static case the exception?
I guess so.
> The first statement above gets at this, but it seems to me that the
> middle ground between random generation per request and permanent
> unique token is worth emphasizing if there will be proxies that want
> to keep per-client identifiers around for some limited amount of time
> that isn't forever.
>
> It's also worth noting that the second statement above is equally true for statically provisioned client IP addresses.
>
> Also, this statement in 8.3 is not really true and probably better left out:
>
> "Proxies using this extension will preserve the information of a
> direct connection, which has an end-user privacy impact, if the end-
> user or deployer does not know or expect that this is the case."
>
> There can certainly be a privacy impact whether the user or deployer has awareness/expectation or not.
Can you give some proof or at least some arguments for this statement?
Cheers,
Andreas
news:6.2.5.6.2.20120729073422.06d8fe10@resistor.net
Hi Yaron,
At 05:52 AM 7/29/2012, Yaron Sheffer wrote:
>this blog post (
>http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/)
>by the editor of OAuth 2.0 made the rounds of
>the geek news outlets: Slashdot, CNet etc. I am
>sure many people on this list have seen it. But
>I have seen no reactions on this list, nor on
>the SAAG list. Is this too unimportant to
>discuss? Is there nothing we, as an organization, can learn from it?
OAuth2 is more within Apps than SAAG. People
discuss about topics they are interested instead
of what you or I would consider as important. I
don't know whether the IETF learns anything from
its failures. It can always redefine failure so
that it becomes known as success. :-)
It is to Eran's credit that he did not seek all
the credit when he could have done so. What I
could learn from that is that "doing the right
thing" will be forgotten when it is convenient to
do so. The WG Chairs did something unusual to
try and resolve the situation. That's in the
mailing list archive for anyone to read if the
person thinks that it is important.
I'll highlight the following:
"[the] working group at the IETF started with
strong web presence. But as the
work dragged on (and on) past its first year,
those web folks left along with
every member of the original 1.0 community.
The group that was left was largely
all enterprise… and me."
It's not the first time that this occurs. It is
up to the IETF to assess whether it is detrimental to have such an outcome.
Regards,
-sm
news:DCC302FAA9FE5F4BBA4DCAD4656937791745A1F0D4@PRVPEXVS03.corp.twcable.com
> From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
> Sent: Saturday, July 07, 2012 5:21 PM
>
> Wes,
>
> Here's my take on this...
>
> CGN as defined in this document does not only include NAT444. It is more
> generic than that: it really means "multi-user NAT". Dave Thaler came up
> with the example use case of the NAT in a wifi hotspot. It's just NAT44,
> but it still fits with the draft's definition of CGN because you have
> multiple users potentially fighting for the same NAT resources. Remember
> that the main raison d'être of this draft is for the operator to be able
> to ensure fairness between NAT users. So in this view I think it is
> clearly behave material since the sunsetting of IPv4 really is
> orthogonal to multi-user NATs.
>
> On the question of IPv6: I don't think we should talk about IPv6 simply
> because IPv6 NAT so far has not seen significant deployment in the
> context of multi-user NAT. And NPTv6 is stateless so there are no
> resources to fight for.
[WEG] I agree with all of what you've said, but I think I need to make the point that I'm concerned with clearer, because the above doesn't exactly address it. I wasn't saying anything about IPv6 NAT, or even IPv4 sunset. I was saying that the current wording is unclear as to what you mean by "IPv4-only". While the NAT specified by this document itself may only act on IPv4 traffic, as you note above it's not limited to just NAT444 or even an IPv4-only *network*. The recommendations in this doc will work for an IPv4 NAT associated with DSLite just as easily as a more traditional IPv4 transport. This is an important distinction, IMO.
>
> Back to your email, where you wrote:
>
> > if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc
> rather than a more generic CGN requirements doc, it should be named to
> reflect that.
>
> How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"?
[WEG] This helps, but only in conjunction with additional clarification about the application - that is, just because the NAT is IPv4-only doesn't mean that the network must also be IPv4-only.
Thanks
Wes George
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
news:50098901.7090009@bogus.com
On 7/20/12 09:06 , IETF Administrative Director wrote:
> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
20 march is palm sunday on the western calender.
If one's a conflict presumably the other is too...
> Ray Pelletier
> IETF Administrative Director
>
news:50098712.6070304@gmail.com
What a perspective refresher - March 2016!
My projects end 2013. Those which have not yet started end 2015.
2015 is the deadline for fire detectors being mandatory in EU.
2018 - maybe a new metro line near where I live, but not known
underground or above.
2016 new presidential elections here, but the precise date may not be set.
2016 is really far away.
Easter - there is almost always a multiple week difference between
Catholic and Orthodox.
Yours,
Alex
Le 20/07/2012 18:06, IETF Administrative Director a écrit :
> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
>
>
news:4FF60B17.1060600@att.com
I've read this version and think it's an excellent revision.
Is there going to be a way of seeing a list of all the versions of the
tao? Or links within tao.html to the previous version? Perhaps a
www.ietf.org/tao/ should be maintained that has pointers to all the
versions as well any proposed update.
Tony Hansen
tony@att.com
On 7/5/2012 5:19 PM, Paul Hoffman wrote:
> Based on many people's input (most recently, John's), I have updated the draft to more cleanly separate out the history of the Tao from the change that is happening.
news:alpine.BSF.2.00.1207231441180.17130@fledge.watson.org
On Fri, 20 Jul 2012, Behcet Sarikaya wrote:
> I don't understand why this issue is coming up.
> Maybe you don't know, IETF 84 falls in the month of Ramadan for
> Muslims and nobody asked to change it?
I think focusing on the religious roots of the holiday is misguided.
The question is what effect the holiday is likely to have on meeting
attendance. I think the IETF also tries to avoid secular holidays
that would interfere with the attendance of a large number of typical
IETF attendees.
Here's an example: we avoid the (secular) Thanksgiving holiday in the
US -- it falls on a Thursday in late November, and it's common for
people to take both the Thursday and Friday as holiday. Thanksgiving
is such a big deal in the US, and we get so many US attendees, that
the IETF would avoid that holiday no matter where the meeting was
being held.
Similarly, I think we would take into account local and regional
holidays at our meeting sites, both religious and secular. We would
probably avoid having a meeting in Amsterdam's center (or, really,
anywhere in the Netherlands) on Queen's Day.
Would overlapping with Easter draw down attendance enough to warrant
avoiding it? Probably. It's a big enough risk that shifting a week
seems sane.
While Ramadan is religiously very significant, I think it is observed
by relatively few of our regular meeting attendees and even those
that do observe it may be willing to travel during it. Hence the
difference in how they're being handled.
-- Sam
news:A29A24B6-4A07-46CC-902B-8A181F0541A3@kumari.net
On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
> The IAOC is seeking community feedback on a proposed policy by the IAOC to impose
> fees to produce information and authenticate documents in response to subpoenas and
> other legal requests.
>
> The IETF receives requests for information, documentation, authentication or other
> matters through subpoenas and less formal means that require manpower and materials
> to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF
> responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three
> other legal requests for authenticated documents.
>
> Each such request is time sensitive and involves the IETF Counsel, the IAD, and members
> of the IAOC, who together form the Legal Management Committee, to rapidly analyze and
> identify the means for satisfying the request. Often there is a need to retain outside counsel,
> especially in cases that might lead to depositions or court testimony.
>
> The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover
> costs associated with such efforts.
>
> The draft policy entitled Draft Fee Policy for Legal Requests can be found
> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Before adopting a policy the IAOC would like feedback on this before making a
> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
>
LGTM++.
Seems like a grand idea -- who knows, may even help avoid nuisance suits (although the fees are so small (compared to all the other costs) that I don't hold much hope of this…).
W
--
For every complex problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken
news:6.2.5.6.2.20120706034122.0c180188@resistor.net
At 20:22 05-07-2012, Tony Hansen wrote:
>I think my point was missed. Section 2 says:
>
>All published versions will be archived using URLs of the form
><http://www.ietf.org/tao-YYYYMMDD.html>.
>
>My question is: Where is there a list of all of the tao version
>files? How would one be able to find out the name of the previous
>version so they could do a diff and see what has changed? How can I
>see a history of the files?
The interesting question is at
http://www.ietf.org/mail-archive/web/ietf/current/msg73889.html I
did not ask Julian whether he was thinking about cool URIs [1]. The
information about common HTTP implementation problems [2] may be
relevant to the discussion. After I read the message at
http://www.ietf.org/mail-archive/web/ietf/current/msg73892.html I
could not understand why it was not possible as there is mod_rewrite.
I don't think that all this is important in a draft which is about of
a tutorial.
Regards,
-sm
1. http://www.w3.org/Provider/Style/URI
2. http://www.w3.org/TR/chips/
news:4FFD8727.4020207@viagenie.ca
On 07/10/2012 10:43 PM, Tina TSOU wrote:
> First, the port numbers to be allocated to CPE. Excluding Well known
> port numbers should be mentioned.
As draft editor, I would ask for a justification. I can't add a
requirement without a justification.
> Moreover if port numbers are allocated
> to each CPE, what is the criteria for allocation.
I don't know, I'm just an editor. What specific text in the draft do you
think needs to be changed?
> As mentioned in the
> document : “ There should be no limit on the size of the address pool”,
> does this address pool imply the one that would be allocated to the CPE?
No. It refers to the external address pool used by the CGN.
> According to the requirement of the CPE, the pool should be allocated or
> a fixed number of addresses in the address pool should be allocated to
> each CPE?
Sorry, I don't understand this question.
> Moreover, the document advocates the use of Endpoint independent
> filtering. If AID is used, there would be a delay of 120 seconds for
> each port reallocation. So should EIF be used only with those
> applications that can’t function without it, instead of applying it for all.
The draft proposes a more conservative approach: use EIF for everything
with ADF exceptions. I understand you propose the reverse: ADF for
everything with EIF exceptions. And I understand that the justification
would be scalability. However, it seems to me that ADF exceptions can be
made for heavy use protocols such as HTTP and DNS to address that
scalability concern. Why isn't that enough?
> The need to maintain a record or database of the allocated ports and
> their lifetime would be helpful.
How could any NAT work without such a database? I probably misunderstand
what you're suggesting...
> If this is maintained, the ports that
> are near to expiring their lifetime would be considered first and
> allocated before and in a order. In such cases there will be less
> chances of the traffic being dropped due to ports not being available.
This seems to go against REQ-11 D.
REQ-11: When a CGN is unable to create a mapping due to resource
constraints or administrative restrictions (i.e., quotas):
D. and it MUST NOT delete existing mappings in order to
"make room" for the new one. (This only applies to
normal CGN behavior, not to manual operator
intervention.)
Are you suggesting that this requirement be dropped? If so, it would be
necessary to demonstrate why the justification for this requirement,
quoted below, is invalid.
Applications generally handle connection establishment failure
better than established connection failure. This is why dropping
the packet initiating the new connection is preferred over
deleting existing mappings. See also the rationale in [RFC5508]
section 6.
> There should be a definite lifetime defined, before connection is
> refused due to unavailability of ports. If there is a threshold of
> say,180 seconds, during which allocated ports database can be scanned
> and if any ports is recently available, can be allocated. This would
> lead to efficient use of ports.
I'm sorry, I don't understand this proposal. Maybe an example would help?
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:5DC517E1-12ED-4DCD-B1F1-8B67157727AA@nordu.net
20 jul 2012 kl. 16:09 skrev "Richard L. Barnes" <rbarnes@bbn.com>:
> +1
>
> Although I wonder whether radical openness would be cheaper in the long run: Put everything online and have an auto-responder at subpoena@ietf.org that says "Go look it up yourself."
>
I could think of some other things it could say too...
> --Richard
>
>
>
> On Jul 20, 2012, at 10:05 AM, Warren Kumari wrote:
>
>>
>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>>
>>> The IAOC is seeking community feedback on a proposed policy by the IAOC to impose
>>> fees to produce information and authenticate documents in response to subpoenas and
>>> other legal requests.
>>>
>>> The IETF receives requests for information, documentation, authentication or other
>>> matters through subpoenas and less formal means that require manpower and materials
>>> to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF
>>> responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three
>>> other legal requests for authenticated documents.
>>>
>>> Each such request is time sensitive and involves the IETF Counsel, the IAD, and members
>>> of the IAOC, who together form the Legal Management Committee, to rapidly analyze and
>>> identify the means for satisfying the request. Often there is a need to retain outside counsel,
>>> especially in cases that might lead to depositions or court testimony.
>>>
>>> The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover
>>> costs associated with such efforts.
>>>
>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>>>
>>> Before adopting a policy the IAOC would like feedback on this before making a
>>> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
>>>
>>> Ray Pelletier
>>> IETF Administrative Director
>>>
>>
>>
>> LGTM++.
>>
>> Seems like a grand idea -- who knows, may even help avoid nuisance suits (although the fees are so small (compared to all the other costs) that I don't hold much hope of this…).
>>
>> W
>>
>> --
>> For every complex problem, there is a solution that is simple, neat, and wrong.
>> -- H. L. Mencken
>>
>>
>>
>
news:201207231704.q6NH4dtB025884@mtv-core-3.cisco.com
At 07:28 AM 7/23/2012, DRAGE, Keith (Keith) wrote:
>Let's forget the religious discussion that seems to have broken out
>as a result of this.
>
>While Easter may be a major Christian festival, I don't believe the
>issue is such (I can think of no reasons why Christians would have a
>doctrinal reason other than those that apply to any other Sunday and
>those obligations could mostly be met at the venue rather than at
>home). Rather it is Easter the secular public holiday that happens
>to occur in many countries.
>
>This is the set of days when schools take an extended break, parents
>take said children off on short holidays; cheap air tickets cease to
>be available; when you get on the plane, it is full of screaming children;
kinda like we're all going to experience at next year's IETF86 timed
exactly in the middle of US spring break going to/from Orlando (home
to 4(?) amusement parks including Disneyworld)?
Air travel will be crazy (families book tickets many months - like 6
- in advance), and depending on which hotel we're in, it could be
worse than staying at the airport each day.
-j
>local transport all works to a reduced timetable; for those IETFers
>who end up wishing to travel by train, they find themselves moving
>to busses to cater for the engineering works which a 4 day weekend
>seems to encourage.
>
>So my advice would be, change the dates if it looks like you are
>going to hold the meeting in a country that takes such holidays, or
>where a significant number of people would need to transit through
>such a country. If so you need to take into account at least both
>the Friday and Monday in some countries.
>
>Keith
>
>P.S. Trying to avoid every religious and public holiday is an
>impossible task. Do what other organizations have done and
>concentrate on the impact of such holidays on holding the meeting in
>any location.
>
> > -----Original Message-----
> > From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
> > Behalf Of IETF Administrative Director
> > Sent: 20 July 2012 17:06
> > To: IETF Announcement List
> > Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org
> > Subject: Proposed IETF 95 Date Change
> >
> > The IAOC is seeking community feedback on a proposed date change for IETF
> > 95
> > scheduled for March 2016.
> >
> > Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is
> > Easter.
> >
> > The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and
> > would like
> > feedback on those dates before making a decision. Comments appreciated to
> > ietf@ietf.org
> > by 6 August 2012.
> >
> > Ray Pelletier
> > IETF Administrative Director
news:80322321-0A40-4F3C-A180-B4AA6AFF4277@cisco.com
On Jul 20, 2012, at 11:37 AM, Behcet Sarikaya wrote:
> I don't understand why this issue is coming up.
> Maybe you don't know, IETF 84 falls in the month of Ramadan for
> Muslims and nobody asked to change it?
Two comments, a question, and a suggestion.
One, the muslims in the crowd had the opportunity, just as anyone else in the IETF did. I don't personally keep track of Ramadan, and I don't expect the muslims to keep track of Easter for me. I was glad to hear Andy's mention of Pesach; that's another one I wouldn't know.
Two - that's a month, not a weekend or a day. The larger the interval you want to put off limits, the more interactions it has.
If you are personally a Muslim, this is a question for you; if not, then its a question for the Muslims on the list.
Easter is a day in which Christians do little besides Easter-related things - sunrise services, egg hunts (which I can explain how they relate to Easter, but you'll laugh, as it has nothing to do with the central issue of Easter), and general family time. Good Friday through Easter, as I mentioned, is a common vacation weekend in Europe apart from religious significance. Pesach (Passover, which is a day, and the days of unleavened bread, which are the following week) is eight days that observing Jews usually spend close to home - or in Jerusalem - for various reasons.
Tell me about Ramadan? My understanding (http://www.wikihow.com/Celebrate-Ramadan) is that during Ramadan one wants to be not far from a Mosque and will want restaurants that cater to ḥalāl (which are generally true anyway). However, what I find on the net and get from Muslim friends is not "don't travel during Ramadan"; it's "travel wisely during Ramadan" (http://islam.about.com/od/dietarylaw/a/halal_travel.htm). Fasting has its issues, but if one is primarily eating after sundown, Muslim restaurants will be open after sundown, which coincidentally is the time that we set aside for dinner.
Is there an expectation among Muslims that travel is to be avoided during Ramadan? Are there specific days in Ramadan that should be spent at home?
I'd suggest that Muslims mark up https://www.ietf.org/registration/MeetingWiki/wiki/ietf84/ with Mosque locations and ḥalāl restaurants.
http://www.islamicfinder.org/prayerDetail.php?city=Vancouver&state=BC&country=canada
news:50085365.6050701@viagenie.ca
Le 2012-07-19 14:20, David Harrington a écrit :
> The IETF could mandate a specific protocol to try to ensure
> interoperability, but doing this takes the decision out of the
> responsibility of the deployer to choose the best solution for the
> deployment environment, and out of the responsibility of the vendor to
> best meet their customers' demands.
> Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB
> might best meet their needs.
> Some vendors might support a Netconf environment and desire a
> Netconf-based configuration solution.
> Some vendors already use AAA widely to control their environment, and
> Diameter NAT control might be preferable.
Careful here. The above protocols are not used between the CPE and the
CGN. The requirement for PCP (or PCP-like) is justified by the need for
subscribers to be able to control the CGN to some extent.
Note also that any of those protocols could also be supported in
addition to PCP, up to the implementer and operator.
> Of course, if CGN is only an ipv4 exit strategy, as is asserted,
Not as asserted by the draft, I hope. We have tried making clear that
CGN as defined in this document really stands for "multi-user NAT" and
that there are use cases that have nothing to do with IPv4 sunset (e.g.
the NAT function in a wifi hotspot is a CGN).
The CGN logical function may or may not be used as part of an IPv4
sunset scenario. As such, it is is absolutely part of behave's core
expertise. Sunset4 could have things to say about how CGN gets applied
to IPv4 sunset, but how CGN behaves is up to behave.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:78374799-AF96-400D-8FB5-205D096CD113@gmx.net
It sounds indeed great to involve those communities that use the technology. However, I don't see an easy way to accomplish that when we talk about a really large community.
For example, many people use TLS and they are not all in the TLS WG working group. I am not even talking about providing useful input to the work (since you would have to be a security expert and some people just want to get their application development done as quickly as possible). They just use the library.
OAuth is a bit similar in that direction. Ideally, we want Web application developers to just use a library and then add their application specific technology on top of it rather than having to read the IETF specification and to write the OAuth code themselves.
On Jul 29, 2012, at 2:13 PM, Worley, Dale R (Dale) wrote:
>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
>>
>> Eran claims that enterprise identity management equipment manufacturer dominate the discussion.
>
> There's a common problem in the IETF that the development of a standard is dominated by companies that incorporate the standard into their products, whereas the people who "really should" be involved in the development are those who will *use* the standard in operation.
>
> Dale
news:9261E011-DA3D-4BDA-A7AF-720C4539BAED@vpnc.org
On Jul 20, 2012, at 9:06 AM, IETF Administrative Director wrote:
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
As much as I would love to see lots of people in their easter bonnets at the meet-and-greet, I think the move is a good one.
As for the Ramadan issue: we've had IETF meetings during Jewish holidays a few times, and folks dealt with it as best they can. If there are some accommodations that can be made at any IETF meeting for different holidays of major religions, I would bet that IETF Secretariat would be glad to hear them.
--Paul Hoffman
news:500C31A2.9050104@gmail.com
On 7/22/12 8:04 AM, John Levine wrote:
> You're not going to find cool temperatures again in July or August
> unless you go as far south as Argentina or New Zealand.
Not only is there life north of the 60th parallel (N), there are
even hotels and restaurants and airports. Anchorage is probably
large enough for an IETF meeting, although trying to hold a meeting
there during tourist season would almost certainly be a mistake.
But still.
Melinda
news:982B8F9A4E5BDC4B89FF7586464DD21901D03AF68449@EXPEXCVS1.hughes.com
I think it should be changed. But, it seems like the week later rather than earlier would be a better choice due to the fact that the week before Easter is often Spring break for many schools, impacting travel and increasing the likelihood of personal conflicts for attendees. Is there a conflict for the week of April 3 that makes it not an option?
John
-----Original Message-----
From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Administrative Director
Sent: Friday, July 20, 2012 12:06 PM
To: IETF Announcement List
Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org; iesg@ietf.org
Subject: Proposed IETF 95 Date Change
The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016.
Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
Ray Pelletier
IETF Administrative Director
news:1342929210.7688.95.camel@gwz-laptop
news:1F9C6238-8DA8-4BB1-AF4E-1ABB9F4B4A80@isoc.org
On Jul 23, 2012, at 4:08 AM, Henk Uijterwaal wrote:
> On 20/07/2012 18:06, IETF Administrative Director wrote:
>> The IAOC is seeking community feedback on a proposed date change for IETF 95
>> scheduled for March 2016.
>>
>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>>
>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
>> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
>> by 6 August 2012.
>>
>> Ray Pelletier
>> IETF Administrative Director
>
> If March 27 is Easter, then I'm not sure if the change solves the problem.
> Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as
> well as the Monday after) are religious holidays in many European countries.
>
> If you want to avoid a clash with Easter and related days, then one will
> have to move the meeting to either the week of 13-18 March,
13 - 18 March 2016 are the dates for the IEEE-802 Plenary.
Ray
> or the week of
> 3-8 April.
>
> Henk
>
>
>
> --
> ------------------------------------------------------------------------------
> Henk Uijterwaal Email: henk(at)uijterwaal.nl
> http://www.uijterwaal.nl
> Phone: +31.6.55861746
> ------------------------------------------------------------------------------
>
> Read my blog at http://www.uijterwaal.nl/henks_hands.html
news:E0BFBA85-85C2-46BA-8406-99990C204295@vigilsec.com
Joe:
>> I think you missed my point. In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier. I do not see a similar concept here.
>
> You're right, I did miss your point, quite thoroughly :-)
>
> I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant CA policy and hence perhaps am still misunderstanding what you're looking for.
So a DNSSEC signer starts under one set of documents, and then for whatever reason, the policy changes and the parties validating the signature have no means to determine that the signer is following a new policy. So I am missing the value of the policy to the parties that rely on these signatures.
Russ
news:tsl4np3h5gg.fsf@mit.edu
>>>>> "David" == David Harrington <ietfdbh@comcast.net> writes:
David> The IETF could mandate a specific protocol to try to ensure
David> interoperability, but doing this takes the decision out of the
David> responsibility of the deployer to choose the best solution for the
David> deployment environment, and out of the responsibility of the vendor to
David> best meet their customers' demands.
This doesn't make any sense to me at all.
It makes sense if the vendor that the ISP is going to use (the CGN
vendor) is somehow related to the vendor that the customer is going to
use (the CPE vendor).
However, one of the explicitly stated assumptions in the behave-lsn
document is that is not the case.
The customer gets to choose a CPE vendor and the operator gets to choose
a CGN vendor.
The deployment environment here is the Internet.
In cases like this in the past we have chosen a technology.
I'm reasonably sure that host requirements mandate DNS as the name
service protocol. We don't want one isp to choose some big LDAP
directory and one ISP to choose DNS.
We want customers name resolution to continue to work (with the same CPE
they already have) as they move from one ISP to another.
The same arguments apply here .
Under the assumptions of this BCP, there is not a boundary between
deployment environments across which one deployment could use PCP and
another SNMP. (I am not aware of netconf schema that does anything
similar to PCP that has been standardized.)
Even obvious deployment environments like cable vs DSL don't make
sense. I can buy my own router and stick it behind either a cable modem
or a DSL router. People often do this. With some ISPs the configuration
gets a little tricky and you may introduce an extra level of
NAT. However, people deploy their own customer gateways on cable, DSL,
even in some cases mobile wireless.
BGP was held up as an example, namely that we don't mandate the
implementation of BGP. Well, not all routers should implement BGP. My
little Linksys box has no need for it. However, if we wrote
requirements for routers participating in the core routing
infrastructure--routers between large organizations and ISP--we'd almost
certainly mandate BGP.
Not all NATs need the same middlebox control protocol. However, this
document does not apply to all NATs. It applies to NATs that cross
organizational boundaries. That's exactly the environment where saying
something like "this is an SNMP deployment," confuses me because I don't
think there will be uniform characterizations of the deployment.
news:20120720155116.91353.qmail@joyce.lan
>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
It seems fine to me, but I would add an hourly rate for research.
For requests for e-mail, do they typically provide pointers to the
specific archive entries, or do they ask for all mail from A on topic
B in month M? In the latter case, a suitable hourly research fee
would likely persuade many lawyers to tell an associate to learn how
to use grep.
R's,
John
PS: Yes, I know it's volunteers. The revenue would go into the cookies fund.
news:CADnDZ89uM25K=8M5KmkFva0V4SHQGUQ2e7nksiv26Pt=WpSrWA@mail.gmail.com
Hi Stewart,
Usually the (IF x, THEN y) means if x happens then y is a MUST, so I
don't see the important reflection of a MUST in many documentation
when using *if*. That is why I prefer to find requirements more easily
while skimming any IETF document, the MUST, SHOULD, and IF, these are
important requirement words in specifications. Please see below as
examples per your requested.
------------------------------------------------------------------------------------------------------
RFC4861>page36> IMO suggest to use IF, THEN
If no entry exists, the sender creates one, sets its state
to INCOMPLETE, initiates Address Resolution, and then queues the data
packet pending completion of address resolution.
------------------------------------------------------------------------------------------------------
RFC4861>page 49> IMO suggest to use IF and ELSE IF
If the router already has a Neighbor Cache entry for the
solicitation’s sender, the solicitation contains a Source Link-Layer
Address option, and the received link-layer address differs from that
already in the cache, then the link-layer address SHOULD be updated
in the appropriate Neighbor Cache entry, and its reachability state
MUST also be set to STALE. If there is no existing Neighbor Cache
entry for the solicitation’s sender, the router creates one, installs
the link- layer address and sets its reachability state to STALE as
specified in Section 7.3.3. If there is no existing Neighbor Cache
entry and no Source Link-Layer Address option was present in the
solicitation, the router may respond with either a multicast or a
unicast router advertisement. Whether or not a Source Link-Layer
Address option is provided, if a Neighbor Cache entry for the
solicitation’s sender exists (or is created) the entry’s IsRouter
flag MUST be set to FALSE.
----------------------------------------------------------------------------------
RFC5715>page 19>
If R changes before T, then a loop will form
around R, T, and S.
-----------------------------------------------------------------------------------
RFC6052> page 10> suggest delete *will* and to add as IF, THEN
If a packet bound to
192.0.2.33 reaches the translator, the destination address will be
translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
routed towards R and then to A.
-----------------------------------------------------------------------------------
There are many examples that ignore the use of IF , THEN requirements,
which I suggest to be in the I-D update of RFC2119 that I working on
and will submit in 30 July,
Regards
Abdussalam Baryun
University of Glamorgan, UK
==================================
>Preferable with a list of RFC text snippets that would have been
>more readable if these keywords had been used.
>Stewart
> On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
> <abdussalambaryun@gmail.com> wrote:
>> Hi All,
>>
>> I am working on an I-D which is intended as proposed standard but need
>> some addition requirement language. Therefore, I want to propose to
>> write a draft to update RFC2119 to add some other language requirement
>> as below:
>>
>> IF x, THEN y:
>>
>> ELSE:
>>
>> ELSE IF:
>>
>> Please send your comments or advise, thanking you,
>
> That doesn't have to be in 2119. Lots of RFCs have pseudocode at
> various levels of rigor. Just look around at some protocol specs for
> examples.
>
news:CAPv4CP-zy1uUqXfXqNH9R1C-NTe+11pxgJ5ceZaR1=oU2E1T=A@mail.gmail.com
>
> > On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
> >> The draft policy entitled Draft Fee Policy for Legal Requests can be
> found
> >> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
Fine idea.
news:07F7D7DED63154409F13298786A2ADC90451F5A8@EXRAD5.ad.rad.co.il
> By cutting the sunrise-to-sunset fasting period of the day to a much shorter period.
Actually, the first day of this IETF (and the last of IETF54) were very interesting
for those fasting on the 9th of Av fast day and having to travel westwards.
Flying west during the fast increases its duration,
for example from Jerusalem to Vancouver there is a 10 hour time zone difference,
so instead of 25 hours the fast increases to 35 hours without food or water.
Y(J)S
news:E045AECD98228444A58C61C200AE1BD807D3E99D@xmb-rcd-x01.cisco.com
Ray:
I'm fine with the change
Cheers,
Pascal
-----Original Message-----
From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Administrative Director
Sent: vendredi 20 juillet 2012 18:06
To: IETF Announcement List
Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org; iesg@ietf.org
Subject: Proposed IETF 95 Date Change
The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016.
Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
Ray Pelletier
IETF Administrative Director
news:20120710132833.0d6d6b02@hetzer
On Mon, 09 Jul 2012 22:48:59 +0100
Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> So I have a question about this draft that wasn't
> resolved on apps-discuss and is maybe more suited
> for IETF LC anyway.
>
> With geopriv, we've gone to a lot of trouble to
> support end-users having some control over their
> location privacy.
"Location Object (LO): An object used to convey location
information together with Privacy Rules. Geopriv supports both
geodetic location data (latitude, longitude, altitude, etc.) and civic
location data (street, city, state, etc.). Either or both types
of location information may be present in a single LO (see the
considerations in [5] for LOs containing multiple locations).
Location Objects typically include some sort of identifier of the
Target."
I'm not really sure that an IP address fits into that description.
If the geopriv thought that an IP address is a LO, they should have
written so in the document.
But more important; I think it would be really unfortunate if the
IETF would encourage people to use IP addresses as location objects, it
is done already, and it works bad and breaks lot of stuff.
> This HTTP header will be used by proxies to forward
> on the IP address of a client, and that will be used
> via geo-ip services to locate the HTTP client.
IP addresses are also forwarded by ISP's routers, I am not
convinced about the big difference here.
It may also be relevant to note that a proxy may not proxy
HTTPS-requests, so in those cases it would be enough to
inline an element served over HTTPS to get the client IP address.
Is that also a privacy issue?
> But in this case, there's no control whatsoever
> for the end user, nor are they even told that
> its happened.
Since it is non-trivial for end users to protect their privacy, I think
education of the end users are the only way to go.
This education is, however, not within the scope of this document.
My point is: privacy and anonymization is hard and hairy, and an
uneducated end user will "never" get this right.
> That seems to me to be quite a disconnect, but
> I'm not sure what if anything ought be done about
> it, since in this case, there's a non-standard
> header that's widely deployed that does this.
>
> So if we did try encourage taking the geopriv
> approach we'd presumably just be ignored.
Yes.
Cheers,
Andreas
news:D7593A6A-41F7-4004-9249-FBBA5030D1C4@cisco.com
On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
> On 7/20/12 09:06 , IETF Administrative Director wrote:
>> The IAOC is seeking community feedback on a proposed date change for IETF 95
>> scheduled for March 2016.
>>
>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>>
>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
>> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
>> by 6 August 2012.
>
> 20 march is palm sunday on the western calender.
>
> If one's a conflict presumably the other is too...
I personally avoid being away from home on Easter, and would prefer that the IETF meeting avoid it.
Yes, Palm Sunday is a question, but not quite on the same scale as Easter. I will note, however, that Good Friday (the Friday before Easter) is a national holiday in a number of countries. People schedule vacations around that weekend.
My suggestion: take the week of April 3 or later.
news:C3C66C81-4FC8-4B26-94D4-C35407A3E265@gmx.net
Eran, the editor of a specification in the OAuth working group, had decided to step down from his editor-role because the group did not agree with certain design decisions (particularly with a security design decision). That happens also in other groups. Nothing uncommon so far.
He then wrote a blog post about his decision and made various claims about lack of interoperability, etc.
This blog post got picked up by the media and various people (who have in many cases not been involved in the IETF OAuth group) turned it into bashing the IETF overall.
On Jul 29, 2012, at 1:18 PM, Worley, Dale R (Dale) wrote:
> Watching a play starting with the third act is always interesting but not informative.
>
> If there's a dispute worthy of attention by the *whole IETF membership*, could someone please summarize it (in a reasonably unbiased way) to bring the rest of us up to speed?
>
> Dale
news:alpine.BSF.2.00.1207221642080.31418@joyce.lan
> I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember)
>
> there were no significant expenses - the depo was in Boston & my only
> expense was a few hours parking - the depo was done in the office of the
> law firm that was providing the IETF with pro-bono legal services at the time
If the opposing party didn't pay you for your time in the depo, you did
them an unnecessary favor.
Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
news:50097FAE.9060805@dcrocker.net
On 7/20/2012 7:25 AM, Richard L. Barnes wrote:
> We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
Do you know that these are acceptable to most/all courts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
news:EDC0A1AE77C57744B664A310A0B23AE240AE8700@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com
Except that there is a cost of taking all the existing paper archives and making them available in such a manner. How many thousand pages are out there?
Keith
> -----Original Message-----
> From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
> Behalf Of Richard L. Barnes
> Sent: 20 July 2012 15:25
> To: Bradner, Scott
> Cc: wgchairs@ietf.org; iab@iab.org; Scott Brim; ietf@ietf.org;
> iaoc@ietf.org
> Subject: Re: Feedback Requested on Draft Fees Policy
>
> [assuming you mean the "go look it up" idea]
>
> We have the technology. Surely a CMS signed object (or even just an HTTPS
> download) would provide adequate authentication that it came from the IETF.
> And it doesn't seem like we would have a problem providing authenticated
> documents to the world.
>
>
>
>
> On Jul 20, 2012, at 10:17 AM, Bradner, Scott wrote:
>
> > great idea - just does not jive with the legal system which often need
> authenticated
> > copies of documents
> >
> > Scott
> >
> > On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
> >
> >>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
> >>>> The draft policy entitled Draft Fee Policy for Legal Requests can be
> found
> >>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
> >>
> >> Fine idea.
> >
> >
> >
news:DA020552-9B8C-45FF-8D89-41894D2C4410@verisign.com
On Jul 30, 2012, at 1:18 PM, Richard L. Barnes wrote:
>>>
>>> MAJOR:
>>>
>>> 4.1.
>>> It's not clear what the threat model is that this section is
>>> designed to address. If the zone operator is malicious, then it can
>>> simulate the necessary zone cut and still prove the non-existence of
>>> records in the child zone.
>>
>> The problem here is not a malicious parent operator, but "an NSEC or
>> NSEC3 RR from an ancestor zone". In the original specification, an
>> attacker could use such an RR to prove the non-existence of some name
>> in a subordinate zone. That was the problem. (Remember, in DNS there
>> is a good chance that you are not talking to an authoritative server.)
>> If you have suggestions on ways to make that clearer, it'd be welcome.
>> The editors tried to come up with compact examples that would be
>> anything other than mystifying, and were unsuccessful.
>
> I guess I still don't understand this. Aren't ancestors the only people that can generate a valid, signed NSEC or NSEC3 RR? So if there were a bad NSEC[3], wouldn't it be the ancestor's fault?
This isn't about "bad NSEC[3]" RRs. It is about an attacker (think "man-in-the-middle") using the valid, completely correct NSEC[3] RR from the parent zone in an inappropriate context.
> If the provisioning is *intentional*, then as I noted before, then there's not really anything to be done, since the ancestor can provide whatever information he wants for the child zones (as above). So are you worried about *inadvertent* provisioning of these bad records?
Again, the record isn't "bad", but being used in the wrong context (either via a software bug or on purpose as an attack). This section isn't about malicious zone operators at all.
I still don't have any great ideas for how to change the text to make this more clear, however.
--
David Blacka <davidb@verisign.com>
Principal Verisign Infrastructure Engineering
news:201207201903.q6KJ3ooZ028685@mtv-core-1.cisco.com
At 12:29 PM 7/20/2012, Fred Baker (fred) wrote:
>On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
>
> > On 7/20/12 09:06 , IETF Administrative Director wrote:
> >> The IAOC is seeking community feedback on a proposed date change
> for IETF 95
> >> scheduled for March 2016.
> >>
> >> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27
> March is Easter.
> >>
> >> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March
> 2016 and would like
> >> feedback on those dates before making a decision. Comments
> appreciated to ietf@ietf.org
> >> by 6 August 2012.
> >
> > 20 march is palm sunday on the western calender.
> >
> > If one's a conflict presumably the other is too...
>
>I personally avoid being away from home on Easter, and would prefer
>that the IETF meeting avoid it.
>
>Yes, Palm Sunday is a question, but not quite on the same scale as
>Easter. I will note, however, that Good Friday (the Friday before
>Easter) is a national holiday in a number of countries. People
>schedule vacations around that weekend.
>
>My suggestion: take the week of April 3 or later.
I agree Easter is a date to avoid, but am not offering which way to
move the meeting. April 3rd of later seems interesting, but does
start to impact the interval between this meeting and the summer one.
James
news:B31EEDDDB8ED7E4A93FDF12A4EECD30D24EAEFB3@GLKXM0002V.GREENLNK.net
I think the main (as in the one more people would care about) issue here (UK) isn't a religious clash, it's a public holiday clash (Friday and Monday).
--
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.dearlove@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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: 21 July 2012 08:16
To: Fred Baker (fred)
Cc: Paul Hoffman; IETF discussion list
Subject: Re: Proposed IETF 95 Date Change
----------------------! 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.
--------------------------------------------------------
On 21/07/2012 02:30, Fred Baker (fred) wrote:
> On Jul 20, 2012, at 6:08 PM, Paul Hoffman wrote:
>
>> As for the Ramadan issue: we've had IETF meetings during Jewish holidays a few times, and folks dealt with it as best they can. If there are some accommodations that can be made at any IETF meeting for different holidays of major religions, I would bet that IETF Secretariat would be glad to hear them.
>
>
> It comes down to adding them to the clash list...
(which is at http://www.ietf.org/meeting/clash-list.html)
And we know that if we did that, on top of all the other technical meetings
that we have to avoid, the result would be overconstrained and scheduling
would become impossible. IMNSHO we need to treat all religious constraints
alike, and in practice that means ignoring them. For practical reasons, we
can't ignore major holidays - not because some of them are religious, but
because they block up hotels and airlines.
Finding the least bad solution is always going to be a compromise, and
I thank the IAOC for continuing to plan several years ahead.
Brian
********************************************************************
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.
********************************************************************
news:CADnDZ89XLoQ6spu7aVyWj8SHE4POEcFVjykAimBnQMUHbwVoyg@mail.gmail.com
comments in line
>
> I'd encourage you to not try change 2119.
thanks for your comment
>
> Instead, add whatever new definitions you feel
> you need to your own draft that addresses some
> technical, and not process, topic.
>
I agree that I will need to add to the technical draft for now.
> If people find your new definitions useful they'll
> say and if enough of that happens they'll be
> included in a 2119bis whenever that's done.
>
this is the reason for this thread to see the feedback of the
community including me (at this time and the comings) and IMO the
submission of the I-D to update RFC2119 that includes new definition
may help the discussion, in the end the community will decide
AB
===
>
> On 07/23/2012 12:08 PM, Abdussalam Baryun wrote:
>> Hi Stewart,
>>
>> Usually the (IF x, THEN y) means if x happens then y is a MUST, so I
>> don't see the important reflection of a MUST in many documentation
>> when using *if*. That is why I prefer to find requirements more easily
>> while skimming any IETF document, the MUST, SHOULD, and IF, these are
>> important requirement words in specifications. Please see below as
>> examples per your requested.
>>
>> ------------------------------------------------------------------------------------------------------
>> RFC4861>page36> IMO suggest to use IF, THEN
>>
>> If no entry exists, the sender creates one, sets its state
>> to INCOMPLETE, initiates Address Resolution, and then queues the data
>> packet pending completion of address resolution.
>> ------------------------------------------------------------------------------------------------------
>> RFC4861>page 49> IMO suggest to use IF and ELSE IF
>>
>> If the router already has a Neighbor Cache entry for the
>> solicitation’s sender, the solicitation contains a Source Link-Layer
>> Address option, and the received link-layer address differs from that
>> already in the cache, then the link-layer address SHOULD be updated
>> in the appropriate Neighbor Cache entry, and its reachability state
>> MUST also be set to STALE. If there is no existing Neighbor Cache
>> entry for the solicitation’s sender, the router creates one, installs
>> the link- layer address and sets its reachability state to STALE as
>> specified in Section 7.3.3. If there is no existing Neighbor Cache
>> entry and no Source Link-Layer Address option was present in the
>> solicitation, the router may respond with either a multicast or a
>> unicast router advertisement. Whether or not a Source Link-Layer
>> Address option is provided, if a Neighbor Cache entry for the
>> solicitation’s sender exists (or is created) the entry’s IsRouter
>> flag MUST be set to FALSE.
>> ----------------------------------------------------------------------------------
>> RFC5715>page 19>
>>
>> If R changes before T, then a loop will form
>> around R, T, and S.
>> -----------------------------------------------------------------------------------
>> RFC6052> page 10> suggest delete *will* and to add as IF, THEN
>>
>> If a packet bound to
>> 192.0.2.33 reaches the translator, the destination address will be
>> translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
>> routed towards R and then to A.
>> -----------------------------------------------------------------------------------
>>
>> There are many examples that ignore the use of IF , THEN requirements,
>> which I suggest to be in the I-D update of RFC2119 that I working on
>> and will submit in 30 July,
>>
>> Regards
>>
>> Abdussalam Baryun
>> University of Glamorgan, UK
>> ==================================
>>
>>> Preferable with a list of RFC text snippets that would have been
>>> more readable if these keywords had been used.
>>
>>> Stewart
>>
>>
>>> On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
>>> <abdussalambaryun@gmail.com> wrote:
>>>> Hi All,
>>>>
>>>> I am working on an I-D which is intended as proposed standard but need
>>>> some addition requirement language. Therefore, I want to propose to
>>>> write a draft to update RFC2119 to add some other language requirement
>>>> as below:
>>>>
>>>> IF x, THEN y:
>>>>
>>>> ELSE:
>>>>
>>>> ELSE IF:
>>>>
>>>> Please send your comments or advise, thanking you,
>>>
>>> That doesn't have to be in 2119. Lots of RFCs have pseudocode at
>>> various levels of rigor. Just look around at some protocol specs for
>>> examples.
>>>
>>
>>
>
news:1343593068.9245.0.camel@gwz-laptop
On Sun, 2012-07-29 at 12:19 -0700, Hannes Tschofenig wrote:
> Just a minor comment on this one:
>
> On Jul 29, 2012, at 8:20 AM, SM wrote:
>
> > "[the] working group at the IETF started with strong web presence. But as the
> > work dragged on (and on) past its first year, those web folks left along with
> > every member of the original 1.0 community. The group that was left was largely
> > all enterprise… and me."
>
> The IETF allows open participation and, as such, everyone, including companies that develop enterprise software, are free to participate in the discussions.
>
> Do you think open participation is wrong?
Do you think that corporate domination of "open" standards development
is OK?
news:7DBE67ABAE8620D11EE70AD6@JCK-EEE10
--On Tuesday, 31 July, 2012 05:41 -0400 Sam Hartman
<hartmans-ietf@mit.edu> wrote:
> I'd probably also recommend excluding paid employees of ISOC.
> I cannot really think of rationale that applies to the
> secretariat staff but not ISOC.
There is one, which is that the IETF and its leadership bodies
have just about zero influence over the recruitment and hiring
of those people. But that same comment applies to IANA staff
(as distinct from the Secretariat). We don't hire them, we
don't pay them, no money passes (in either direction) between
ICANN/IANA and the IASA/IETF, etc.
In theory, we could "designate" some other entity as the IANA,
which might or might not cost some current IANA staff their
jobs. But there are questions about how realistic that is (not
part of this discussion). We certainly cannot fire ISOC and,
given their charter, it isn't clear they could fire us. If they
could, they'd have to fire the entire IETF, not individuals. I
suppose one could argue that ISOC staff might have undue
influence on the behavior of the ISOC BoT as a confirming body,
but I find that really dubious.
john
news:4FF4AEDB.5030209@bogus.com
On 7/4/12 11:49 AM, John Levine wrote:
>> NANOG is around 500 attendees. I daresay exposure to the average nanog
>> attendee is worth more, but ultimately the best feedback in that regard
>> will likely come from the sponsors.
> IETF is bigger, but on the other hand, IETF attendees probably spend
> less per capita on equipment than NANOGers do.
Yeah, that's what I said. ;)
If pitched correctly the folks that would be interested in the IETF
community might not be equipment vendors. e.g. I* organizations,
standards bodies doing outreach, contractors that provider services to
organziations doing standards works, patent trolls with portfolios to
sell and regular participants looking to rasie the visibility of their
activities all seem like potential participants.
> It's an experiment, if we're turning away sponsors and people think it
> was overall a success, we can raise the price. If not, well, we can
> do something else.
Indeed. A lot of things I might not be willing to support in the general
case are fine in the guise of experiments.
> R's,
> John
>
news:CAJNg7VKqbdXeFXCe6iBRPe=X89q4NuSVcgvmc+C=t0826HRwiA@mail.gmail.com
On Sun, Jul 22, 2012 at 10:54 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> In theory yes, a signed document would be sufficient.
>
> In practice it would then require an expert witness at $400/hr to
> explain that it meant it was authentic.
>
The depositions are typically to state that the RFC's etc. posted on
line are, to the best of our knowledge and ability, the true RFC's,
etc. So, there would likely still need to be depositions stating that,
signed documents or no.
Remember the basic way that subpoenas work : The IETF is served with a
legal document _demanding_ something, backed by the force of law.
Yes, we typically then point out that much of what they want is
available on line, and frequently negotiate with opposing counsel to
moderate demands for depositions, etc., but, in the end, we propose,
the judge and opposing counsel dispose. That won't change.
Regards
Marshall
> The schedule of fees seems a reasonable response to a real cost being
> imposed on the organization.
>
> On Fri, Jul 20, 2012 at 10:25 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
>> [assuming you mean the "go look it up" idea]
>>
>> We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
>>
>>
>>
>>
>> On Jul 20, 2012, at 10:17 AM, Bradner, Scott wrote:
>>
>>> great idea - just does not jive with the legal system which often need authenticated
>>> copies of documents
>>>
>>> Scott
>>>
>>> On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
>>>
>>>>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>>>>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>>>>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>>>>
>>>> Fine idea.
>>>
>>>
>>>
>>
>
>
>
> --
> Website: http://hallambaker.com/
news:5017B60D.5050101@pi.nu
Scott,
would you say that drafts aimed for experimental status are "standards
work".
/Loa
On 2012-07-30 18:33, Scott O Bradner wrote:
> 2804 does not say not to talk about such things - or that such documents should
> not be published as RFCs - 2804 says that the IETF will not do standards work
> in this area
>
> Scott
>
> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>
>> Under the long-standing IETF policy defined in RFC 2804, I trust
>> we will not be discussing this draft, or
>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>
>> Regards
>> Brian Carpenter
>>
>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
>>> Author(s) : Shankar Raman
>>> Balaji Venkat Venkataswami
>>> Gaurav Raina
>>> Vasan Srini
>>> Bhargav Bhikkaji
>>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>> Pages : 12
>>> Date : 2012-07-30
>>>
>>> Abstract:
>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>> models like VPLS and the like do not have any provider provisioned
>>> methods of lawful intercept that are comprehensive, quick and easy to
>>> provision from one single point. More particularly the auto-
>>> provisioning of lawful intercept for all sets of streams travelling
>>> between VPN sites and consequent re-direction of these streams to the
>>> appropriate government network has not been covered without multiple
>>> instances of having to configure the intercept at various points in
>>> the network both in the Single-AS case and the Inter-Provider VPN
>>> case.
>>>
>>> this paper, we propose a technique which uses a set of pre-defined
>>> labels called Lawful Intercept labels and a method for provisioning
>>> lawful intercept amongst the various PE devices using these labels
>>> both in the Single-AS and the inter-provider VPN cases. A single
>>> point of configuration is the key to this idea. The intercepted
>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>> participating in the VPN. A technique called the Domino-effect
>>> provisioning of these Label-based Provider Provisioned Lawful
>>> Intercept mechanism is also outlined.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>
--
Loa Andersson email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager loa@pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
news:m2ipd5w3um.wl%randy@psg.com
> 2804 does not say not to talk about such things - or that such documents should
> not be published as RFCs - 2804 says that the IETF will not do standards work
> in this area
for those of us who are easily confused, could you differentiate between
working on douments and publishing them as rfcs from doing standards
work?
randy
news:CAHBDyN77p5UPJsb8Of_KZhcvpnkzAQ4t+L+7sUkm02d_GNuY_w@mail.gmail.com
I don't think we should try to factor in Spring Break. Personally, I like
it when the meeting overlaps with Spring Break because that introduces the
possibility that my sons can travel with me depending upon the locale
(they're old enough to care for themselves during the day). Even if they
are at home, I am much comfortable with not having to worry about their
school activities while I am gone. Also, the range of dates for Spring
Break is extremely broad in my experience.
So, this is very much a YMMV situation. While I very much disliked not
being at home during Easter (and very much disliked missing Halloween when
kids were young), it has happened and while it's not ideal, it just comes
with a job that requires travel of an incredibly diverse group of people.
As was pointed out by Richard with the 2016 dates, it's impossible to avoid
religious holidays across the board (in particular given that many want the
week before and the week after religious holiday weeks for various
reasons).
Regards,
Mary.
On Fri, Jul 20, 2012 at 11:53 AM, John Border <John.Border@hughes.com>wrote:
>
> I think it should be changed. But, it seems like the week later rather
> than earlier would be a better choice due to the fact that the week before
> Easter is often Spring break for many schools, impacting travel and
> increasing the likelihood of personal conflicts for attendees. Is there a
> conflict for the week of April 3 that makes it not an option?
>
>
> John
>
>
> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:
> ietf-announce-bounces@ietf.org] On Behalf Of IETF Administrative Director
> Sent: Friday, July 20, 2012 12:06 PM
> To: IETF Announcement List
> Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org;
> iesg@ietf.org
> Subject: Proposed IETF 95 Date Change
>
> The IAOC is seeking community feedback on a proposed date change for IETF
> 95 scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is
> Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and
> would like feedback on those dates before making a decision. Comments
> appreciated to ietf@ietf.org by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
>
news:500C56F3.6090909@gmail.com
On 7/22/12 11:25 AM, John Levine wrote:
> I believe it, but remember that the issue was to minimize daylight fasting
> during the North American summer.
Moderate temperatures were thrown into the mix, which I guess provides
a pretty good illustration of the challenges of making everybody happy.
Frankly, I understand that some people have health challenges that
make it important to avoid very hot weather but for the most part I
think people should stop being such delicate flowers and just deal with
it (and I say this as someone who really, really dislikes hot weather).
At any rate, I'm really not sure what to do about the religious holiday
situation although I tend to agree that it might not be a terrible idea
to treat all religions equally, even if ultimately that means ignoring
all religious holidays for scheduling purposes.
Melinda
news:0B751F7F-3AF8-4AF2-92C0-3D384FBCD4C4@ietf.org
The memorial service for RL "Bob" Morgan will take place on Sunday. Since many of his friends will be in Vancouver for the IETF meeting, we have arranged a room at the Hyatt hotel to receive the broadcast from the the memorial as it takes place in Seattle. If you want to participate, please come to Regency F from 11:00AM - 2:00PM on Sunday.
I miss RL "Bob" Morgan. I am sure many others in the IETF community do as well.
Russ
On Jul 18, 2012, at 3:00 PM, =JeffH wrote:
> Hi,
>
> I'm very sorry for repetition if you've already heard this, and sorrier still to feel compelled to bring it to you all's broad attention in any case...
>
> RL "Bob" Morgan, long-time IETF participant (since at least the Stanford IETF-14 in Summer 1989), passed away due to complications of cancer on 12-Jul-2012.
>
> He is sorely missed, and IETF meetings/activities won't seem the same without his most trenchant perspectives, observations, contributions, and camaraderie.
>
> For more information and tributes, see..
>
> https://spaces.internet2.edu/display/rlbob/
>
>
> =JeffH
>
news:CAJNg7V+GrzOcLKkHcVkxy07pjgvBjFuO8HOsyTSNQYjs-uoJ1A@mail.gmail.com
On Fri, Jul 20, 2012 at 9:23 AM, Jiankang Yao <yaojk@cnnic.cn> wrote:
>
>
> I have taken a look at this policy. but still not very clear about this
> policy.
>
> could you kindly show some examples for charging the fee?
>
>
I looked at this before the policy was created.
Many internet companies do this.
Yahoo :
http://cryptome.org/isp-spy/yahoo-spy.pdf
• Basic subscriber records: approx. $20 for the first ID, $10 per ID thereafter
• Basic Group Information (including information about moderators):
approx. $20 for a group with a single moderator
• Contents of subscriber accounts, including email: approx. $30-$40
per user • Contents of Groups: approx. $40 - $80 per group
Verizon :
http://www.verizon.net/policies/civil_subpoena.asp
Verizon Online charges the following rates for compliance with civil
subpoenas and other legal process. For subpoenas and other legal
process that require substantial effort by Verizon Online, Verizon
Online reserves the right to charge a rate of $75 per hour (plus
overtime costs if necessary) and to collect an estimated fee in
advance. Except as set forth in the preceding sentence, Verizon
Online's subpoena compliance fees and charges are as follows:
$40.00 per IP record requested (unless overtime charges apply)
$22.00 per Federal Express or actual shipping charges if higher
$0.25 cents per copy
Sprint
http://info.publicintelligence.net/SprintSubpoenaManual.pdf
Lots of different fees. Minimum $50.00 administrative processing fee
for Civil requests.
AT&T
https://contact.bellsouth.com/subpoena/
Fees for Subpoena Processing: AT&T charges a fee for the processing of
civil subpoenas.
I do not think that the fees suggested here are at all out of line
with either the actual burden or with what other organizations do.
Regards
Marshall
>
> Jiankang Yao
>
> ----- Original Message ----- From: "IETF Administrative Director"
> <iad@ietf.org>
> To: "IETF Announcement List" <ietf-announce@ietf.org>
> Cc: <iaoc@ietf.org>; <iab@iab.org>; <ietf@ietf.org>; <wgchairs@ietf.org>
> Sent: Friday, July 20, 2012 9:07 PM
> Subject: Feedback Requested on Draft Fees Policy
>
>
>
> The IAOC is seeking community feedback on a proposed policy by the IAOC to
> impose
> fees to produce information and authenticate documents in response to
> subpoenas and
> other legal requests.
>
> The IETF receives requests for information, documentation, authentication or
> other
> matters through subpoenas and less formal means that require manpower and
> materials
> to be expended. These requests are on the rise. During the period 2005 to
> 2010 the IETF
> responded to nine subpoenas. Since 2011 the IETF has received five
> subpoenas and three
> other legal requests for authenticated documents.
>
> Each such request is time sensitive and involves the IETF Counsel, the IAD,
> and members
> of the IAOC, who together form the Legal Management Committee, to rapidly
> analyze and
> identify the means for satisfying the request. Often there is a need to
> retain outside counsel,
> especially in cases that might lead to depositions or court testimony.
>
> The IAOC believes a Schedule of Fees is an appropriate and reasonable means
> to recover
> costs associated with such efforts.
>
> The draft policy entitled Draft Fee Policy for Legal Requests can be found
> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Before adopting a policy the IAOC would like feedback on this before making
> a
> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
>
news:20120710060912.GA19405@1wt.eu
On Mon, Jul 09, 2012 at 10:48:59PM +0100, Stephen Farrell wrote:
>
> So I have a question about this draft that wasn't
> resolved on apps-discuss and is maybe more suited
> for IETF LC anyway.
>
> With geopriv, we've gone to a lot of trouble to
> support end-users having some control over their
> location privacy.
>
> This HTTP header will be used by proxies to forward
> on the IP address of a client, and that will be used
> via geo-ip services to locate the HTTP client.
In practice, the real use for the header is in the reverse-proxy chain,
as many people already disable x-forwarded-for on outgoing proxies for
privacy concerns. And server-side generally ignores the untrustable
x-forwarded-for provided by clients anyway. In the abstract, the draft
says it's for use between trusted proxies, which generally means either
the client-side proxy chain for logging purposes, where the last one
will remove the info, or more generally the server side where everyone
appends itself.
Maybe a small paragraph on this might emphasize the intended purpose
and suggest use cases as well as software options to add/ignore/remove
the header depending on the proxy location in the chain.
Regards,
Willy
news:9B2F2766-DB92-4B7B-88DC-1B90FF6707B7@bbn.com
+1
Although I wonder whether radical openness would be cheaper in the long run: Put everything online and have an auto-responder at subpoena@ietf.org that says "Go look it up yourself."
--Richard
On Jul 20, 2012, at 10:05 AM, Warren Kumari wrote:
>
> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>
>> The IAOC is seeking community feedback on a proposed policy by the IAOC to impose
>> fees to produce information and authenticate documents in response to subpoenas and
>> other legal requests.
>>
>> The IETF receives requests for information, documentation, authentication or other
>> matters through subpoenas and less formal means that require manpower and materials
>> to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF
>> responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three
>> other legal requests for authenticated documents.
>>
>> Each such request is time sensitive and involves the IETF Counsel, the IAD, and members
>> of the IAOC, who together form the Legal Management Committee, to rapidly analyze and
>> identify the means for satisfying the request. Often there is a need to retain outside counsel,
>> especially in cases that might lead to depositions or court testimony.
>>
>> The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover
>> costs associated with such efforts.
>>
>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>>
>> Before adopting a policy the IAOC would like feedback on this before making a
>> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
>>
>> Ray Pelletier
>> IETF Administrative Director
>>
>
>
> LGTM++.
>
> Seems like a grand idea -- who knows, may even help avoid nuisance suits (although the fees are so small (compared to all the other costs) that I don't hold much hope of this…).
>
> W
>
> --
> For every complex problem, there is a solution that is simple, neat, and wrong.
> -- H. L. Mencken
>
>
>
news:8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu
On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:
> Joe Touch wrote:
>
>>> Or, are 6 to 4 translators are required to rate limit and
>>> drop rate-violating packets to make the "stateless"
>>> translators full of states.
>>
>> I would expect that the translator would be responsible
>> for this, though
>
> Do you mean translators must rate limit, or translators
> violate RFC2765:
Translators violate RFC791. They cannot merely copy the low-order bits of the field, since that is insufficiently unique, and isn't specified as being generated at the IPv6 source in compliance with IPv4 requirements.
>> there is the problem that multiple translators interfere
>> with each other.
>
> Yes, even rate limiting translators may interfere each other,
> which means rate limiting must be done at the IPv6 source
> node.
>
>> Regardless, this is outside the scope of the ipv4-id-update doc.
>
> In the ID, there are a lot of references to IPv6.
It quotes IPv6 examples, but does not propose to change IPv6 processing. That may be needed, but that would be outside the scope of this doc.
> For example, the following statement of the ID:
>
> Finally, the IPv6 ID field is
> 32 bits, and required unique per source/destination address pair for
> IPv6, whereas for IPv4 it is only 16 bits and required unique per
> source/destination/protocol triple.
>
> must be modified as:
>
> Finally, the IPv6 ID field is
> 32 bits, but lower 16 bits are required unique per
> source/destination address pair for
> IPv6,
That's incorrect as per RFC2460. Other RFCs may violate that original spec, but that needs to be cleaned up separately.
Joe
news:1343595120.6354.2.camel@gwz-laptop
On Sun, 2012-07-29 at 23:37 +0300, Yoav Nir wrote:
...
> >> The IETF allows open participation and, as such, everyone, including companies that develop enterprise software, are free to participate in the discussions.
> >>
> >> Do you think open participation is wrong?
> >
> > Do you think that corporate domination of "open" standards development is OK?
>
> Hi
>
> Like Dale, I haven't followed the play throughout the life of OAuth (the working group)
>
> Who are these corporations that dominate the working group?
The particulars are immaterial. The question was as general (& I
suppose, philosophical) as Hannes'.
> Are they content providers like Facebook, Twitter, or Disney? Are they ISPs? Is it General Motors?
>
> If they are the people who are supposed to use these standards, their participation is a good thing. I wish we had more users (corporate or others) in the Security Area. So who are they?
>
> Yoav
news:6E526B78-44AD-44F3-A5FB-F42D3DBEE4B0@vigilsec.com
Dan:
Only protocol specifications make use of Ethertypes. The statement is intended to apply to any protocol specification on the IETF Stream (Standards Track RFC, Informational RFC, or Experimental RFC) that needs to allocate a new Ethertype.
Russ
On Jul 30, 2012, at 5:20 PM, Romascanu, Dan (Dan) wrote:
>
>
> (I hope not to open some Pandora box or a long thread - my goal is to
> make sure there is clarity in the language of the statement)
>
> What 'IETF protocol specification' means here?
>
> Pretty clear it covers protocols defined in IETF standards-track
> documents.
>
> Does it also cover protocols defined (described) in Informational RFCs
> which are part of the IETF stream?
>
> Dan
>
>
>> -----Original Message-----
>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
>> bounces@ietf.org] On Behalf Of IETF Chair
>> Sent: Monday, July 30, 2012 7:40 PM
>> To: IETF Announce
>> Cc: IETF
>> Subject: Draft IESG Statement Regarding Ethertype Requests
>>
>> Last week the IAB and the IESG met with the leadership of IEEE 802.
> One
>> of the things that was discussed was the IEEE policies for allocating
>> EtherTypes, and the IESG is considering the attached IESG Statement to
>> implement an IETF policy that aligns with the IEEE policy.
>>
>> If you have an comments on this proposed policy, please raise them on
>> ietf@ietf.org.
>>
>> Russ
>>
>> = = = = = =
>>
>> The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
>> (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF
>> protocol specification make use of Ethertypes. Since Ethertypes are a
>> fairly scarce resource, the IEEE RAC will not assign an Ethertype to a
>> new IETF protocol specification that needs a new Ethertype until the
>> IESG has approved the specification for publication as an RFC.
>>
>> To let the IEEE RAC know that the IESG has approved an IETF protocol
>> specification for publication, all future requests for assignment of
>> Ethertypes for IETF protocol specifications will be made by the IESG.
>>
>> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for
> use
>> during development and experimentation.
>>
>>
>> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
>> IEEE standard for Local and Metropolitan Area Networks:
>> Overview and Architecture -- Amendment 1: Ethertypes for
>> Prototype and Vendor-Specific Protocol Development.
news:1876CD0A-DD0A-4253-B559-0A4F041DA3DE@checkpoint.com
On Jul 29, 2012, at 1:17 PM, Glen Zorn wrote:
> On Sun, 2012-07-29 at 12:19 -0700, Hannes Tschofenig wrote:
>>
>> Just a minor comment on this one:
>>
>> On Jul 29, 2012, at 8:20 AM, SM wrote:
>>
>> > "[the] working group at the IETF started with strong web presence. But as the
>> > work dragged on (and on) past its first year, those web folks left along with
>> > every member of the original 1.0 community. The group that was left was largely
>> > all enterprise… and me."
>>
>> The IETF allows open participation and, as such, everyone, including companies that develop enterprise software, are free to participate in the discussions.
>>
>> Do you think open participation is wrong?
>
> Do you think that corporate domination of "open" standards development is OK?
Hi
Like Dale, I haven't followed the play throughout the life of OAuth (the working group)
Who are these corporations that dominate the working group? Are they content providers like Facebook, Twitter, or Disney? Are they ISPs? Is it General Motors?
If they are the people who are supposed to use these standards, their participation is a good thing. I wish we had more users (corporate or others) in the Security Area. So who are they?
Yoav
news:20120723202556.0B8481A0E7@ld9781.wdf.sap.corp
John Levine wrote:
[ Charset UTF-8 unsupported, converting... ]
> >> You're not going to find cool temperatures again in July or August
> >> unless you go as far south as Argentina or New Zealand.
> >
> >Not only is there life north of the 60th parallel (N), there are
> >even hotels and restaurants and airports. Anchorage is probably
> >large enough for an IETF meeting, although trying to hold a meeting
> >there during tourist season would almost certainly be a mistake.
> >But still.
>
> I believe it, but remember that the issue was to minimize daylight fasting
> during the North American summer.
>
> Reykjavik is big enough, too, and has the advantage of being roughly
> equally inconvenient to get to from North America and Europe. We
> could have the social event at the Blue Lagoon.
The issue with Reykjavik is more about is closeness to the Arctic circle.
You don't seem to have a lot of sunset&night there during the summer.
Take into account that ramadan is related to the lunar calender and
is 11 days earlier every year to the next (on the gregorian calendar)
then a hypothetical IETF meeting in Reykjavik, 22th June - 26th June 2015
could turn out "challenging" for some folks. The currently scheduled
date for IETF 93 is 19-24 July, 2015, so I assume it will be after Ramadan.
-Martin
news:CAC4RtVDEYMWLbNcekVM0YEgMa872C8wgZPj-vY6M7P=BPuJcgQ@mail.gmail.com
>
> does get into other details which can influence the selection process.
> If the objective is to avoid self-selection, one could question the
> process for the appointment of the NomCom Chair.
>
The NomCom chair does not have a vote on the NomCom, and is just a process
facilitator. That's for exactly this reason.
Barry
news:20120722050117.5538.qmail@joyce.lan
>I see. Well, look on the bright side: the meeting could have been in
>Reykjavik ;-).
Yes, that would have been bright, wouldn't it?
R's,
John
PS: sure like those hot dogs, though.
news:6.2.5.6.2.20120709134136.0ad9ae18@resistor.net
At 11:27 09-07-2012, Alissa Cooper wrote:
>Is it possible to recommend that generated tokens have limited
>lifetimes (per-request or otherwise), and make the static case the
>exception? The first statement above gets at this, but it seems to
>me that the middle ground between random generation per request and
>permanent unique token is worth emphasizing if there will be proxies
>that want to keep per-client identifiers around for some limited
>amount of time that isn't forever.
Yes.
>It's also worth noting that the second statement above is equally
>true for statically provisioned client IP addresses.
>
>Also, this statement in 8.3 is not really true and probably better left out:
>
>"Proxies using this extension will preserve the information of a
> direct connection, which has an end-user privacy impact, if the end-
> user or deployer does not know or expect that this is the case."
I suggest removing that statement. The wording is not entirely
clear. I read it as diluting end-user privacy impact.
In Section 6.3:
'To distinguish the obfuscated identifier from other identifiers,
it MUST have a leading underscore "_".'
I suggest removing the requirement and using "can". The implementer
can decide what to put in that field.
Regards,
-sm
news:tsld3425jor.fsf@mit.edu
Hi. I'd like to speak in favor of maintaining endpoint independent
filtering as the default and maintaining requirement 11 D. I think
requirement 11 D is important for avoiding some hard to analyze but
potentially very dangerous security problems. If I can trick a NAT into
replacing an existing mapping by causing resource exhaustion then I
could probably attack that. Unfortunately such attacks tend to appear
minor or hard to exploit until someone puts together what turns out to
be a fairly reliable exploit against some equipment, then you have a
real mess.
I believe the stability of application argument argues for endpoint
independent filtering.
news:m2pq7e7g9a.wl%randy@psg.com
http://www.scifac.ru.ac.za/cspt/hoare.htm
news:20120711.163444.104075113.miyakawa@nttv6.jp
Tina,
Thanks for the comment.
> First, the port numbers to be allocated to CPE. Excluding Well known port numbers should be mentioned.
I think that even if well know port is allocated as src address,
there would be no problem.
The document is aiming at "minimal" set of requirements to make CGN transparent,
I agree with that this could be helpful
but I don't think this is a critical condition to make this I-D an RFC, isn't it ?
> Moreover if port numbers are allocated to each CPE, what is the criteria for allocation.
I think that it's operators' choice :-)
<snip>
> Some amount of clarity in this respect would be helpful.
I also think this kind of information is usuful, but
this could be discussed in other draft isn't it ?
> Moreover, the document advocates the use of Endpoint independent filtering. If AID is used, there would be a delay of 120 seconds for each port reallocation. So should EIF be used only with those applications that can’t function without it, instead of applying it for all.
I see... Especially, Simon, how do you think ?
>
> The need to maintain a record or database of the allocated ports and their lifetime would be helpful.
For example, if port is statically assigned, there is no need to have
such record. So, again, I agree with that this is of course a clue to
operate CGN better in certain environment, but still is not a critical, I think.
So, how about we could create a document with such a hint for CGN operation
seprately then let this I-D move forward now ? > Tina
Best wishes,
Shin Miyakawa
news:CD5674C3CD99574EBA7432465FC13C1B22726A0BC7@DC-US1MBEX4.global.avaya.com
Watching a play starting with the third act is always interesting but not informative.
If there's a dispute worthy of attention by the *whole IETF membership*, could someone please summarize it (in a reasonably unbiased way) to bring the rest of us up to speed?
Dale
news:CABkgnnUawpB6Z_jec+wwHk3SpNU=Tkt5J+YYNsME2YWWUHk4aA@mail.gmail.com
On 21 July 2012 06:55, Yoav Nir <ynir@checkpoint.com> wrote:
> This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
But moving it to the southern hemisphere would have.
news:50107BEF.4040901@dcrocker.net
On 7/25/2012 3:54 PM, Randall Gellens wrote:
> I may have a room at the Hyatt at CAD 194 (includes breakfast) for the
> full IETF week. If anyone wants it, please let me know right away.
I could use a room at the Hyatt, but only for that Friday night.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
news:82AB329A76E2484D934BBCA77E9F524924D0B4E4@PALLENE.office.hd
Hi Martin,
thanks for the review and advice.
I'd agree that the "confirmation use case" should be highlighted (described better) . Will do that by adding some text along the lines you mentioned to the intro.
How about this:
----
In addition, we also define a ".well-known" URL equivalent, and a way to include a hash as a segment of an HTTP URL, as well as a binary format for use in protocols that require more compact names. Moreover, we define a human-speakable text form that allows for reading out (and understanding) names so that they can be transferred over voice connections, which can be used for verifying the presence of an adequate hash or key information.
----
As to the detailed suggestions, I don't think it is really necessary to rename 'nih' to 'fingerprint' and to get rid of "Human-speakable" as a description for it. In the end, those URIs are essentially "human-speakable" -- so that they can be used for confirming the presence/absence of resources.
I don’t like 'fingerprint' as a scheme identifier, because a) those URIs, unlike PK fingerprints, actually contain the complete hash information and b) because it does not convey the relationship to 'ni'. I think it's fine to stick to 'nih' here.
I agree that the nid separators can be useful. Would be OK for me to still add them.
Thanks,
Dirk
-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of "Martin J. Dürst"
Sent: Montag, 2. Juli 2012 13:07
To: Stephen Farrell
Cc: Graham Klyne; ietf@ietf.org
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
Hello Stephen,
On 2012/06/26 20:26, Stephen Farrell wrote:
>
> Hi again Martin,
>
> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>> So the question is really, what's the use case, and what's just a
>> consequence of that use case. If confirmation of already available
>> resources (e.g. like a fingerprint) is the (main?) use case, and the
>> greater weight on "speakability" just a design consequence, then it
>> makes sense to have two separate things.
>
> Yes, confirmation is the main current use-case for nih as I understand
> it and have said previously.
I sincerely wish you had said this so clearly much, much earlier, or even better that it had been in the draft in cristal clear language. We could have avoided a lot of useless discussion.
> (Of course the resource might not yet
> be present, so "already available" isn't quite right, but that's a
> nit.)
>
> Have we beaten this to death sufficiently now? I hope so;-)
>
> If you want to suggest a sentence that says that, feel free.
I really don't think it should be my job to explain this. There are enough coauthors on the draft who should be in a much better position than myself to write such text :-(.
Anyway, here is a try:
- In the abstract, replace "and binary and human "speakable" formats for these names" by ", a binary form, and a form for confirming the presence (or absence) of resources".
- In the introduction, replace "and a
human-speakable text form that could be used, e.g. for reading out
(parts of) the name over a voice connection." with
"and a form optimized for confirming the presence (or absence) of
resources by humans.".
- Change the title of Section 7 from "Human-speakable Format" to "Format for Resource Confirmation"
- Replace the first sentence at the start of Section 7 to say:
There is often a need for humans to confirm that a particular resource, e.g. a public key, is already present, or to discover its absence.
- Change "("speaking" the value of an ni URI)" to "confirm the presence or absence of a resource")
- Nuke the second paragraph of section 7 (the one that starts with "The justification for using a URI"). The stuff it says about IDNs, for example, isn't really appropriate for IETF standardization.
- In the example section, change "Human-speakable form of a name" to "Form for resource confirmation" (three occurrences).
I'd also change the "nih:" scheme to something like "fingerprint:", and allow the insertion of delimiter characters (allowing e.g.
nih:3;5326-9057-e12f-e2b7-4ba0-7c89-2560a2;f instead of nih:3;53269057e12fe2b74ba07c892560a2;f because the former should be much easier to manipulate by humans), but I guess I'd again be shot down for "proposing something like this at such a late date" (I note we are still in IETF Last Call).
Regards, Martin.
news:DEAC0B5D-DC0D-4198-BA42-B4E7329395B8@tzi.org
On Jul 23, 2012, at 14:28, DRAGE, Keith (Keith) wrote:
> you need to take into account at least both the Friday and Monday in some countries.
+1
In much of Europe, the Easter holidays run from Good Friday to Easter Monday, and exhibit
-- strong travel activity
-- zero to reduced opening times of various essential facilities
-- reduced public transport schedules (*)
When meeting in Europe, avoid both weeks around Easter.
(Clearly, we need to have IETF95 in Bali. :-)
Grüße, Carsten
(*) A bit counterintuitive -- the reason is that public transport agencies tend to cater to their employees as opposed to their customers, and these employees want to enjoy the holidays, too.
Since everybody knows that public transport is overcrowded on these long weekends, there isn't even any backlash.
news:2A3DE550-E441-469D-9A7D-4844838B8B6B@tzi.org
Not yet quite optimal for e.g. RFC 3095:
http://tools.ietf.org/tools/citation/?doc=3095&template=%7Bauthors.andlist%7D%2C+%22%7Bdoctitle%7D%2C%22+%7Bdocname%7D%2C+%7Bdate%3A%25B+%25Y.%7D&submit=Generate+citation
Grüße, Carsten
news:1657B5B7-4680-4E32-991F-10BC70A84347@bbn.com
[assuming you mean the "go look it up" idea]
We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
On Jul 20, 2012, at 10:17 AM, Bradner, Scott wrote:
> great idea - just does not jive with the legal system which often need authenticated
> copies of documents
>
> Scott
>
> On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
>
>>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>>
>> Fine idea.
>
>
>
news:80A0822C5E9A4440A5117C2F4CD36A6403FCEC31@DEMUEXC006.nsn-intra.net
> I sincerely thank Matt for his willingness to take on this task as it
requires a tremendous time commitment and dedication to do well.
+1. It is indeed a huge effort for the Nomcom chair and all voting
members especially between September and January.
Cheers,
Mehmet
From: ext Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, July 04, 2012 7:24 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: ietf@ietf.org; ext Lynn St.Amour
Subject: Re: IETF Nominations Committee Chair - 2012 - 2013
Mehmet,
In my experience, the most important characteristic for a nomcom chair
is the ability to lead a group of 10 volunteers (usually with a
significant variation of experience in IETF) through the process as
defined by RFC 3777 (and 5680). It can be good for a chair to have
past Nomcom experience, but I do not believe that is a hard requirement
(I had never served on a Nomcom before I was chair). It can be good for
a Nomcom chair to have been a WG chair as they can understand more about
the process. BUT, the chair is not the decision maker - the voting
members are - the most important thing is for the chair to be able to
facilitate the process as defined. It's far more important for the
voting members to have that knowledge than the chair. Now, it can be
more challenging if a chair hasn't been involved in IETF for a while,
but AFAIK, Matt has been involved in the RAI area (as a
participant/contributor) for a while and if you google you can find he's
also been involved in the Security area on the SECDIR. You can see the
work he's been involved in here in authorstats:
http://www.arkko.com/tools/allstats/mattlepinski.html
Honestly, one of the most important aspect of the Nomcom process is for
the Nomcom to get community feedback. You can read my report from
2009-2010 and that is an issue as the information that the nomcom is
working with typically is extremely incomplete. Many nomcom voting
members have little experience with interviewing and hiring "employees".
You also have to keep in mind that the past Nomcom chair serves as an
advisor for the current Nomcom chair, which dramatically reduces the
risk in the case that the appointed chair runs into problems.
I sincerely thank Matt for his willingness to take on this task as it
requires a tremendous time commitment and dedication to do well.
Regards,
Mary.
On Wed, Jul 4, 2012 at 4:18 AM, Ersue, Mehmet (NSN - DE/Munich)
<mehmet.ersue@nsn.com> wrote:
Hi,
it's time again for Nomcom. Congrats and good luck to Matt Lepinski.
I have to admit I don't know him. I assume this is my issue as I'm an
OPS guy and not much involved in atoca or geopriv.
Having been active in two Nomcoms, I am wondering what a useful
selection criteria for a Nomcom chair could be.
Having experience as a WG chair or having been active as Nomcom voting
member?
I can imagine a retired AD would enjoy it and do an excellent job in
this position.
Cheers,
Mehmet
From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext Lynn St.Amour
Sent: Tuesday, July 03, 2012 10:31 PM
To: IETF Announcement list
Subject: IETF Nominations Committee Chair - 2012 - 2013
To the IETF community,
One of the roles you entrusted to the Internet Society (ISOC) President
& CEO is to appoint the IETF Nominations Committee chair. This is done
through consultation with the IETF community.
It gives me great pleasure to announce that Matt Lepinski has agreed to
serve as the 2012 - 2013 IETF Nominations Committee chair.
A Call for Nominations for this committee will be sent to the IETF
Announcement list; and a list of the IESG, IAB and IAOC/IETF Trust seats
to be filled will be published shortly. Please give serious
consideration to volunteering for the Nominations Committee as well as
to possible candidates for the open positions.
The NomComm process is central to the IETF's success, and it is
important that it have the support of the IETF community. In the
interim, feel free to make your suggestions known to Matt, who will
share them with the committee once it is seated. Matt can be reached
at: Matthew Lepinski <mlepinski.ietf@gmail.com>
Thank you in advance for your support and a sincere thank you to Matt
for agreeing to take on this very significant responsibility.
Regards,
Lynn St. Amour
President & CEO
Internet Society (ISOC)
news:CAHBDyN7FcwYespTTwvj_myV9E_AexmyLnbZbhWnwCGqM+pOSNA@mail.gmail.com
Mehmet,
In my experience, the most important characteristic for a nomcom chair is
the ability to lead a group of 10 volunteers (usually with a significant
variation of experience in IETF) through the process as defined by RFC
3777 (and 5680). It can be good for a chair to have past Nomcom
experience, but I do not believe that is a hard requirement (I had never
served on a Nomcom before I was chair). It can be good for a Nomcom chair
to have been a WG chair as they can understand more about the process. BUT,
the chair is not the decision maker - the voting members are - the most
important thing is for the chair to be able to facilitate the process as
defined. It's far more important for the voting members to have that
knowledge than the chair. Now, it can be more challenging if a chair
hasn't been involved in IETF for a while, but AFAIK, Matt has been involved
in the RAI area (as a participant/contributor) for a while and if you
google you can find he's also been involved in the Security area on the
SECDIR. You can see the work he's been involved in here in authorstats:
http://www.arkko.com/tools/allstats/mattlepinski.html
Honestly, one of the most important aspect of the Nomcom process is for the
Nomcom to get community feedback. You can read my report from 2009-2010 and
that is an issue as the information that the nomcom is working with
typically is extremely incomplete. Many nomcom voting members have little
experience with interviewing and hiring "employees". You also have to keep
in mind that the past Nomcom chair serves as an advisor for the current
Nomcom chair, which dramatically reduces the risk in the case that the
appointed chair runs into problems.
I sincerely thank Matt for his willingness to take on this task as it
requires a tremendous time commitment and dedication to do well.
Regards,
Mary.
On Wed, Jul 4, 2012 at 4:18 AM, Ersue, Mehmet (NSN - DE/Munich) <
mehmet.ersue@nsn.com> wrote:
> Hi,****
>
> ** **
>
> it’s time again for Nomcom. Congrats and good luck to Matt Lepinski.****
>
> I have to admit I don’t know him. I assume this is my issue as I’m an OPS
> guy and not much involved in atoca or geopriv.****
>
> ** **
>
> Having been active in two Nomcoms, I am wondering what a useful selection
> criteria for a Nomcom chair could be.****
>
> Having experience as a WG chair or having been active as Nomcom voting
> member?****
>
> I can imagine a retired AD would enjoy it and do an excellent job in this
> position.****
>
> ** **
>
> Cheers,
> Mehmet ****
>
> ** **
>
> *From:* ietf-announce-bounces@ietf.org [mailto:
> ietf-announce-bounces@ietf.org] *On Behalf Of *ext Lynn St.Amour
> *Sent:* Tuesday, July 03, 2012 10:31 PM
> *To:* IETF Announcement list
> *Subject:* IETF Nominations Committee Chair - 2012 - 2013****
>
> ** **
>
> To the IETF community,
>
> One of the roles you entrusted to the Internet Society (ISOC) President &
> CEO is to appoint the IETF Nominations Committee chair. This is done
> through consultation with the IETF community.
>
> It gives me great pleasure to announce that Matt Lepinski has agreed to
> serve as the 2012 - 2013 IETF Nominations Committee chair.
>
> A Call for Nominations for this committee will be sent to the IETF
> Announcement list; and a list of the IESG, IAB and IAOC/IETF Trust seats to
> be filled will be published shortly. Please give serious consideration to
> volunteering for the Nominations Committee as well as to possible
> candidates for the open positions.
>
> The NomComm process is central to the IETF's success, and it is important
> that it have the support of the IETF community. In the interim, feel free
> to make your suggestions known to Matt, who will share them with the
> committee once it is seated. Matt can be reached at: Matthew Lepinski <
> mlepinski.ietf@gmail.com>
>
> Thank you in advance for your support and a sincere thank you to Matt for
> agreeing to take on this very significant responsibility.
>
> Regards,
>
> Lynn St. Amour
>
> President & CEO
> Internet Society (ISOC)****
>
> ** **
>
> ** **
>
news:25428E776486D6F2DF98C25B@JcK-HP8200.jck.com
--On Friday, July 06, 2012 00:28 -0400 Tony Hansen
<tony@att.com> wrote:
> Authoritative, no. But definitely referenced by many, many
> people and IMO worthy of a certain amount of care.
No disagreement about care. But it seems to me that adequate
care requires keeping track of a future version, a current
version, and a previous version (or maybe two). The ability to
easily find and trace back through the entire history of the
document seems appropriate for something normative but well
beyond what is required for reasonable care with a document like
this.
Just my opinion, however. I have trouble convincing myself that
the issue is really important enough to hold things up.
john
news:4FF659F0.1020104@att.com
I think my point was missed. Section 2 says:
All published versions will be archived using URLs of the form
<http://www.ietf.org/tao-YYYYMMDD.html>.
My question is: Where is there a list of all of the tao version files?
How would one be able to find out the name of the previous version so
they could do a diff and see what has changed? How can I see a history
of the files?
Here is a suggested addition to section 2:
Each version of the Tao will also have a link to a history page of
all versions.
Or something like that. The mechanics what that page looks like can be
determined later -- it doesn't really matter right now, nor does it
matter right now what the address is.
Tony Hansen
On 7/5/2012 6:02 PM, Paul Hoffman wrote:
> On Jul 5, 2012, at 2:45 PM, Tony Hansen wrote:
>
>> Is there going to be a way of seeing a list of all the versions of the tao? Or links within tao.html to the previous version? Perhaps a www.ietf.org/tao/ should be maintained that has pointers to all the versions as well any proposed update.
>
> I think the Tao web page should point to RFC 4677 in a "well, how did I get here?" section, given that this is not the same as it ever was.
news:FEE0CA44-A470-434A-9F25-88089411D0A6@bbn.com
On Jul 20, 2012, at 11:56 AM, Dave Crocker wrote:
> On 7/20/2012 7:25 AM, Richard L. Barnes wrote:
>> We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
>
>
> Do you know that these are acceptable to most/all courts?
>
> d/
IANAL, so no. But what else are we going to provide that's better?
--Richard
news:C91E67751B1EFF41B857DE2FE1F68ABA0BCF7C76@TK5EX14MBXC273.redmond.corp.microsoft.com
Very useful document, certainly worth publishing. It is one of those documents that needs frequent updates.
RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators, makes reference to a predecessor of this document, stating in section 3.1 that "The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]." I assume that implementers will automatically upgrade their code to reference the new version.
-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Randy Bush
Sent: Friday, July 13, 2012 4:21 PM
To: IETF Disgust; The IESG
Subject: Re: Last Call: <draft-vegoda-cotton-rfc5735bis-02.txt> (Special Use IPv4 Addresses) to Best Current Practice
> The IESG has received a request from an individual submitter to
> consider the following document:
> - 'Special Use IPv4 Addresses'
> <draft-vegoda-cotton-rfc5735bis-02.txt> as Best Current Practice
read and support
randy
news:6.2.5.6.2.20120711154825.09f09be8@resistor.net
Hi Andreas,
At 06:41 11-07-2012, Andreas Petersson wrote:
>How is it "random bits of information" when the specifications says
>that it MUST be underscore?
>
>As far as I can think of, the only thing that it will tell is that the
>implementation is following this specification.
>So, on the contrary; the more "degrees of freedom" that is given to the
>implementation, the easier it would be to do fingerprinting.
I could use a hash. If the hash has to begin with an underscore, I
have to reserve storage space for it. The ease for fingerprinting
depends on how Section 6.3 is implemented (see reference I posted on
WG mailing list about browser identification). I am ok if you want
to keep the requirement.
Regards,
-sm
news:5016C98A.9020200@gmail.com
Yes, Scott, that is correct, sorry for my poor phrasing.
Brian
On 30/07/2012 17:33, Scott O Bradner wrote:
> 2804 does not say not to talk about such things - or that such documents should
> not be published as RFCs - 2804 says that the IETF will not do standards work
> in this area
>
> Scott
>
> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>
>> Under the long-standing IETF policy defined in RFC 2804, I trust
>> we will not be discussing this draft, or
>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>
>> Regards
>> Brian Carpenter
>>
>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
>>> Author(s) : Shankar Raman
>>> Balaji Venkat Venkataswami
>>> Gaurav Raina
>>> Vasan Srini
>>> Bhargav Bhikkaji
>>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>> Pages : 12
>>> Date : 2012-07-30
>>>
>>> Abstract:
>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>> models like VPLS and the like do not have any provider provisioned
>>> methods of lawful intercept that are comprehensive, quick and easy to
>>> provision from one single point. More particularly the auto-
>>> provisioning of lawful intercept for all sets of streams travelling
>>> between VPN sites and consequent re-direction of these streams to the
>>> appropriate government network has not been covered without multiple
>>> instances of having to configure the intercept at various points in
>>> the network both in the Single-AS case and the Inter-Provider VPN
>>> case.
>>>
>>> this paper, we propose a technique which uses a set of pre-defined
>>> labels called Lawful Intercept labels and a method for provisioning
>>> lawful intercept amongst the various PE devices using these labels
>>> both in the Single-AS and the inter-provider VPN cases. A single
>>> point of configuration is the key to this idea. The intercepted
>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>> participating in the VPN. A technique called the Domino-effect
>>> provisioning of these Label-based Provider Provisioned Lawful
>>> Intercept mechanism is also outlined.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>
>
news:C4BC366A-7A75-40A8-86AB-5C2C2B8262F3@standardstrack.com
We seem to be doing a lot of talking about the draft.
On Jul 30, 2012, at 9:33 AM, Scott O Bradner wrote:
> 2804 does not say not to talk about such things - or that such documents should
> not be published as RFCs - 2804 says that the IETF will not do standards work
> in this area
>
> Scott
>
> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>
>> Under the long-standing IETF policy defined in RFC 2804, I trust
>> we will not be discussing this draft, or
>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>
>> Regards
>> Brian Carpenter
>>
>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
>>> Author(s) : Shankar Raman
>>> Balaji Venkat Venkataswami
>>> Gaurav Raina
>>> Vasan Srini
>>> Bhargav Bhikkaji
>>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>> Pages : 12
>>> Date : 2012-07-30
>>>
>>> Abstract:
>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>> models like VPLS and the like do not have any provider provisioned
>>> methods of lawful intercept that are comprehensive, quick and easy to
>>> provision from one single point. More particularly the auto-
>>> provisioning of lawful intercept for all sets of streams travelling
>>> between VPN sites and consequent re-direction of these streams to the
>>> appropriate government network has not been covered without multiple
>>> instances of having to configure the intercept at various points in
>>> the network both in the Single-AS case and the Inter-Provider VPN
>>> case.
>>>
>>> this paper, we propose a technique which uses a set of pre-defined
>>> labels called Lawful Intercept labels and a method for provisioning
>>> lawful intercept amongst the various PE devices using these labels
>>> both in the Single-AS and the inter-provider VPN cases. A single
>>> point of configuration is the key to this idea. The intercepted
>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>> participating in the VPN. A technique called the Domino-effect
>>> provisioning of these Label-based Provider Provisioned Lawful
>>> Intercept mechanism is also outlined.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>
news:5005EC6A.8030805@qualcomm.com
On 7/17/12 5:14 PM, John C Klensin wrote:
> --On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
> <presnick@qualcomm.com> wrote:
>
>
>> Perhaps I'm just being contrarian today, but I *do* think this
>> document should be BCP and not Informational. It is not a
>> requirements document in the sense that it is laying out
>> requirements for future protocol documents being developed by
>> a WG; it is a consensus document listing the requirements for
>> the operation and administration of a type of device. If that
>> doesn't fall within the 2nd paragraph of RFC 2026 section 5, I
>> don't know what does.
>>
> Just to be disagreeable...
>
> I think "requirements for the operation and administration of a
> type of device" puts it squarely into the "Applicability
> Statement" range, in part of permit testing of those
> requirements and advancement along the standards track. Of
> course, the precedent is RFCs 1122 and 1123 which requirements
> for operation and administration as well as for protocol
> conformance and are clearly applicability statements (and more
> or less the prototype for that category).
>
Just to be somewhat agreeable... ;-)
Normally, I would be right with you and say, "This should be on the
standards track." However, this document is about CGNs. It's about
things that are almost by definition not nice interoperable players on
the Internet. They are messy local devices for (albeit large) local
networks. Indeed, there are many folks who think that horrific plagues
be visited upon those who deploy CGNs and that they should be dismantled
as soon as humanly possible, if not before. But in any event, this is
not really a spec "for hardware and software required for computer
communication across interconnected networks", but rather is a document
for "networks operated by a great variety of organizations, with diverse
goals and rules" to provide "operators and administrators of the
Internet follow some common guidelines for policies and operations". Or
at least I think a strong case can be made for that. I think that's why
several other behave documents ended up being BCPs. I could make an
argument for standards track, but I think BCP is a reasonable
alternative conclusion to come to as well for this particular document.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
news:20120720132302.GA3594@mail.yitter.info
On Fri, Jul 20, 2012 at 06:07:33AM -0700, IETF Administrative Director wrote:
> Before adopting a policy the IAOC would like feedback on this before making a
> decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
I think this is a perfectly legitimate policy, and I support it. The
fees don't seem to be outrageous to me.
Best,
A
--
Andrew Sullivan
ajs@anvilwalrusden.com
news:1343595740.6354.10.camel@gwz-laptop
On Sun, 2012-07-29 at 13:28 -0700, Hannes Tschofenig wrote:
> >
> > Do you think that corporate domination of "open" standards development is OK?
> >
>
> The barrier for participation is low since there are no membership fees, etc.
For participation, yes, all that is needed is an email account; if one
wishes to attend meetings (just the main ones - let's ignore interims),
the bar rises considerably. The chances of dominating a WG or attaining
a leadership position in the IETF are very close to zero without meeting
attendance. I spend about 10% of my gross income on travel, meeting
fees, etc. for IETF meetings; I don't consider that to be trivial.
> Nevertheless, those who participate in standardization efforts have to spend their time.
And somebody's money: I spend about 10% of my gross income on travel,
meeting fees, etc. for IETF meetings; I don't consider that to be
trivial.
> So, typically those who participate for a longer period of time need to have some incentives. These incentives often come from working for a specific company.
>
> We cannot force anyone to participate in any of our working groups. In the OAuth case we have lots of other people participating but they typically ask questions and provide implementation feedback rather than trying to steer the standardization work.
>
> Ciao
> Hannes
>
> PS: Eran was also working for a big corporation, namely Yahoo. I could imagine that Yahoo also had some incentives to pay Eran for his participation in this work.
news:1342857902.7688.13.camel@gwz-laptop
On Sat, 2012-07-21 at 01:30 +0000, Fred Baker (fred) wrote:
> On Jul 20, 2012, at 6:08 PM, Paul Hoffman wrote:
>
> > As for the Ramadan issue: we've had IETF meetings during Jewish holidays a few times, and folks dealt with it as best they can. If there are some accommodations that can be made at any IETF meeting for different holidays of major religions, I would bet that IETF Secretariat would be glad to hear them.
>
>
> It comes down to adding them to the clash list...
Wow, if I'd known that before I'd have added my daughter's birthday (9
Nov) to the list about 25 years ago; maybe I wouldn't have been at IETF
meetings for all but two...
news:20120722192519.18622.qmail@joyce.lan
>> You're not going to find cool temperatures again in July or August
>> unless you go as far south as Argentina or New Zealand.
>
>Not only is there life north of the 60th parallel (N), there are
>even hotels and restaurants and airports. Anchorage is probably
>large enough for an IETF meeting, although trying to hold a meeting
>there during tourist season would almost certainly be a mistake.
>But still.
I believe it, but remember that the issue was to minimize daylight fasting
during the North American summer.
Reykjavik is big enough, too, and has the advantage of being roughly
equally inconvenient to get to from North America and Europe. We
could have the social event at the Blue Lagoon.
R's,
John
news:500D0674.2090303@gmail.com
On 20/07/2012 18:06, IETF Administrative Director wrote:
> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
If March 27 is Easter, then I'm not sure if the change solves the problem.
Sunday March 20 is Palm Sunday, the Thursday and Friday before Easter (as
well as the Monday after) are religious holidays in many European countries.
If you want to avoid a clash with Easter and related days, then one will
have to move the meeting to either the week of 13-18 March, or the week of
3-8 April.
Henk
--
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk(at)uijterwaal.nl
http://www.uijterwaal.nl
Phone: +31.6.55861746
------------------------------------------------------------------------------
Read my blog at http://www.uijterwaal.nl/henks_hands.html
news:C18E588A-541E-43C7-AF41-F301E3A6AE5B@cs.columbia.edu
There are a number of very weird entries that require special handling. I (also) wrote a Python script to convert the XML file to bibtex and had to deal with a number of these special cases. For example, RFC 4534 lists the authors as "A Colegrove, H Harney" instead of "A. Colegrove, H. Harney". Other names like "The Internet Society" require special handling. And I completely punted on proper capitalization of the titles; I just accept what's there.
On Jul 31, 2012, at 2:23 PM, Ole Jacobsen wrote:
>
> Mehmet,
>
> The tool is not INTENDED to change the author order. A somewhat
> incomplete database can indeed lead to unexpected results, use with
> caution.
>
> Ole
>
> Ole J. Jacobsen
> Editor and Publisher, The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
> Skype: organdemo
>
>
> On Tue, 31 Jul 2012, Ersue, Mehmet (NSN - DE/Munich) wrote:
>
>> Nice tool.
>>
>> However, I am wondering why the tool changes the order of the names.
>> There is actually a reason why documents list names in a specific order.
>>
>> Some of the citations appear to be incomplete, see RFC3410.
>>
>> Cheers,
>> Mehmet
>>
>>
>>> -----Original Message-----
>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
>> Of ext Ole
>>> Jacobsen
>>> Sent: Tuesday, July 31, 2012 11:17 AM
>>> To: The IETF
>>> Cc: RSOC; Heather Flanagan; rsag@rfc-editor.org
>>> Subject: RFC and I-D Citation Tool
>>>
>>>
>>> In The Internet Protocol Journal I have been using the following
>>> citation format, best illustrated by an example:
>>>
>>> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
>>> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
>>> Paths (LSPs)," RFC 6387, September 2011.
>>>
>>> So, that's full author names "and" before the last author name, title,
>>> document number and date, using the American "quotation outside
>>> punctuation rule."
>>>
>>> I got tired of doing this "by hand" so I asked Henrik if he could
>>> write me a tool. He did (THANKS!), and the result is here:
>>>
>>> http://tools.ietf.org/tools/citation/
>>>
>>> This will take either the draft name or the RFC number as input and
>>> produce a citation similar to the one above. You can of course play
>>> with the elements and generate a format that suits your own taste, for
>>> example, for I-Ds, in print it might be good to have the FILE NAME as
>>> the last entry:
>>>
>>> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
>>> Internet Draft, work in progress, July 2011,
>>> draft-agl-dane-serializechain-01
>>>
>>> ...since I like having filenames or URLs on one line (not wrapping)
>>> as much as possible.
>>>
>>> Many thanks again to Henrik, and I hope you will find it useful too!
>>>
>>> Ole
>>>
>>>
>>>
>>> Ole J. Jacobsen
>>> Editor and Publisher, The Internet Protocol Journal
>>> Cisco Systems
>>> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
>>> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
>>> Skype: organdemo
>>
>>
>
--Steve Bellovin, https://www.cs.columbia.edu/~smb
news:5AAD9253-F597-4B57-9BA8-C067B3E3839D@hopcount.ca
Hi Russ,
On 2012-07-17, at 19:06, Russ Housley wrote:
> I think you missed my point. In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier. I do not see a similar concept here.
You're right, I did miss your point, quite thoroughly :-)
I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant CA policy and hence perhaps am still misunderstanding what you're looking for.
Joe
news:90AB01B9-F750-4671-A611-7D1651A2C49F@netapp.com
And for those of us who write academic papers, there is of course Roland's and Miguel's BibTex collections:
http://tm.uka.de/~bless/bibrfcindex.html
https://sites.google.com/site/ea1dof/bibtex
Lars
On Jul 31, 2012, at 11:16, Ole Jacobsen <ole@cisco.com> wrote:
>
> In The Internet Protocol Journal I have been using the following
> citation format, best illustrated by an example:
>
> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
> Paths (LSPs)," RFC 6387, September 2011.
>
> So, that's full author names "and" before the last author name, title,
> document number and date, using the American "quotation outside
> punctuation rule."
>
> I got tired of doing this "by hand" so I asked Henrik if he could
> write me a tool. He did (THANKS!), and the result is here:
>
> http://tools.ietf.org/tools/citation/
>
> This will take either the draft name or the RFC number as input and
> produce a citation similar to the one above. You can of course play
> with the elements and generate a format that suits your own taste, for
> example, for I-Ds, in print it might be good to have the FILE NAME as
> the last entry:
>
> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
> Internet Draft, work in progress, July 2011,
> draft-agl-dane-serializechain-01
>
> ...since I like having filenames or URLs on one line (not wrapping)
> as much as possible.
>
> Many thanks again to Henrik, and I hope you will find it useful too!
>
> Ole
>
>
>
> Ole J. Jacobsen
> Editor and Publisher, The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
> Skype: organdemo
>
news:39B73AD9-4E8F-4E94-A538-69BE5D8C0E18@gmx.net
Just a minor comment on this one:
On Jul 29, 2012, at 8:20 AM, SM wrote:
> "[the] working group at the IETF started with strong web presence. But as the
> work dragged on (and on) past its first year, those web folks left along with
> every member of the original 1.0 community. The group that was left was largely
> all enterprise… and me."
The IETF allows open participation and, as such, everyone, including companies that develop enterprise software, are free to participate in the discussions.
Do you think open participation is wrong?
news:B69FC36D-4EE1-4132-9E43-D730093DD9AD@vpnc.org
On Jul 22, 2012, at 9:56 AM, Melinda Shore wrote:
> I'd be a lot more comfortable with people describing/speaking up
> for their own religious requirements.
That's no fun. We're much more loquacious when we're talking about other peoples religions, other people's laws, other people's gender issues, other people's food sensitivities, and so on.
news:3B377A30-123B-4772-AAB8-FAA535FDD0BE@sobco.com
I did not do them any favor - I did the IETF a favor (as the then ISOC VP for Standards)
Scott
On Jul 22, 2012, at 4:43 PM, John R Levine wrote:
>> I did it once - it took 2 or 3 hours *it was quite a while back and I do not remember)
>>
>> there were no significant expenses - the depo was in Boston & my only
>> expense was a few hours parking - the depo was done in the office of the
>> law firm that was providing the IETF with pro-bono legal services at the time
>
> If the opposing party didn't pay you for your time in the depo, you did them an unnecessary favor.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
news:5006DC70.7000500@bbn.com
Joe
>> You're right, I did miss your point, quite thoroughly :-)
>>
>> I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant CA policy and hence perhaps am still misunderstanding what you're looking for.
In X.509 each cert can contain a policy OID that indicates the policy
under which the cert was issued. Thus, when a CA changes it's policy it
can issue certs under the new policy with the new policy OID. This makes
it clear to relying parties what policy is in effect, and when a CA
changes its policy, irrespective of
other changes, e.g., key rollover.
Steve
news:31E58CB3-05F6-4E74-ABD3-C87BB2662897@bbn.com
For convenience, the complete list:
<http://www.interfaithcalendar.org/2016.htm>
On Jul 20, 2012, at 1:44 PM, Andrew G. Malis wrote:
> As long as you don't go any later than the week of April 10 - the week
> of April 17 runs into the start of Passover.
>
> Thanks,
> Andy
>
> On Fri, Jul 20, 2012 at 1:29 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>>
>> On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
>>
>>> On 7/20/12 09:06 , IETF Administrative Director wrote:
>>>> The IAOC is seeking community feedback on a proposed date change for IETF 95
>>>> scheduled for March 2016.
>>>>
>>>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>>>>
>>>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
>>>> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
>>>> by 6 August 2012.
>>>
>>> 20 march is palm sunday on the western calender.
>>>
>>> If one's a conflict presumably the other is too...
>>
>> I personally avoid being away from home on Easter, and would prefer that the IETF meeting avoid it.
>>
>> Yes, Palm Sunday is a question, but not quite on the same scale as Easter. I will note, however, that Good Friday (the Friday before Easter) is a national holiday in a number of countries. People schedule vacations around that weekend.
>>
>> My suggestion: take the week of April 3 or later.
news:27AA7B5C-F989-4C51-BFB1-1BE0316F6101@vigilsec.com
Mehmet:
This is the price that NANOG charges for a table at their Beer-n-Gear event. I think that access to the IETF community is worth roughly the same price. We can reevaluate the price once there is feedback on the experiment. It might go up, It might go down.
Russ
On Jul 4, 2012, at 5:34 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi Russ, All,
>
> was there also a discussion on the contribution?
> $10**4 for two hours chat with potential customers does not look very
> motivating.
> As this is an experiment I would actually start with less obstacles and
> see how it evolves.
>
> Cheers,
> Mehmet
>
>
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> Of ext Russ
>> Housley
>> Sent: Thursday, June 28, 2012 8:41 PM
>> To: Thomas Nadeau
>> Cc: IETF discussion list
>> Subject: Re: bits-n-bites: Exhibitors and product vendors hawking
> wares at anIETF
>> meeting?
>>
>> There was a long discussion about this event prior to it being
> scheduled. Sorry you
>> missed that discussion.
>>
>> We will have a discussion after the event to determine if we should do
> it again.
>>
>> Russ
>>
>>
>> On Jun 28, 2012, at 2:23 PM, Thomas Nadeau wrote:
>>
>>>
>>> Has the IETF morphed into a conference/convention?
>>>
>>> http://www.ietf.org/meeting/84/bits-n-bites.html
>>>
>>>
>
news:5009BADF.9030602@bogus.com
On 7/20/12 12:42 , Mary Barnes wrote:
> Also, the range of
> dates for Spring Break is extremely broad in my experience.
More than 6 months inclusive of the southern hemisphere.
news:500447D9-AF64-4924-9DB1-0E5408318070@gmail.com
It is my understanding that for these types of reasons (and others), folks who are adhering to Ramadan can eat while traveling and if they are sick.
And agreed to previous point that the southern hemisphere may have been less impacting in this particular case (given overlap during IETF in northern hemisphere In summer). That said, moving the meeting further south would have helped as well vs. How far north Vancouver is.
Victor K
Sent from my iPad
On 2012-07-22, at 2:36 AM, Yaakov Stein <yaakov_s@rad.com> wrote:
>
>> By cutting the sunrise-to-sunset fasting period of the day to a much shorter period.
>
> Actually, the first day of this IETF (and the last of IETF54) were very interesting
> for those fasting on the 9th of Av fast day and having to travel westwards.
>
> Flying west during the fast increases its duration,
> for example from Jerusalem to Vancouver there is a 10 hour time zone difference,
> so instead of 25 hours the fast increases to 35 hours without food or water.
>
> Y(J)S
>
news:6.2.5.6.2.20120730101231.047f2550@resistor.net
Hi Hannes,
At 12:19 PM 7/29/2012, Hannes Tschofenig wrote:
>The IETF allows open participation and, as such, everyone, including
>companies that develop enterprise software, are free to participate
>in the discussions.
>
>Do you think open participation is wrong?
It depends on what open participation means in the above. If it is
open participation by companies, I don't have any problem with it as
long as the relevant BCPs are updated to reflect that.
At 11:14 AM 7/29/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>I would find it useful if anyone of you who likes to agree or
>disagree to have at least read the OAuth specification. I had
>noticed that many of those who share their valuable thoughts have
>not even spent the time to look at the document.
I wonder whether I read the OAuth2 specifications. :-)
Regards,
-sm
news:C7F4D01F-B0A0-4CBE-B68D-CEB68385CCAA@gmail.com
You can just plan one at anytime but in the early morning. This would help and will come before the tiring part is taking place.
Best Regards
Muhammad Badi
On Jul 21, 2012, at 4:55 PM, Yoav Nir wrote:
>
> On Jul 21, 2012, at 10:00 AM, Eliot Lear wrote:
>
>> I'd support a date change for IETF 95 but it should be the week of the
>> 14th to take into account Palm Sunday and Good Friday. As to Ramadan, I
>> too would like to understand if there is a need to take this holiday
>> into account, and what would be the practical way to do that?
>
> My Moslem coworkers, some more observant, some less so, all come to work on Ramadan. Ramadan lasts a whole month (well, a whole lunar cycle), and involves fasting from sunrise to sunset. This is relatively OK when Ramadan falls in winter, but more painful when it falls in summer.
>
> This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
>
> Yoav
news:m2vch3sy8v.wl%randy@psg.com
> I'd probably also recommend excluding paid employees of ISOC. I cannot
> really think of rationale that applies to the secretariat staff but
> not ISOC.
perhaps we should take the leap of assuming folk are adults here (i
realize it is a stretch), and not start a black-list with no proof of
termination.
randy
news:20120710132825.5141babe@hetzer
On Mon, 09 Jul 2012 13:59:43 -0700
SM <sm@resistor.net> wrote:
> >Also, this statement in 8.3 is not really true and probably better left out:
> >
> >"Proxies using this extension will preserve the information of a
> > direct connection, which has an end-user privacy impact, if the end-
> > user or deployer does not know or expect that this is the case."
>
> I suggest removing that statement. The wording is not entirely
> clear. I read it as diluting end-user privacy impact.
I interpret it the other way around.
It makes a deployer aware that there is also end user expectations
to take into considerations.
Removing it may work as well, but I think that less well reflects the
discussion on the apps-list.
> In Section 6.3:
>
> 'To distinguish the obfuscated identifier from other identifiers,
> it MUST have a leading underscore "_".'
>
> I suggest removing the requirement and using "can". The implementer
> can decide what to put in that field.
I think that will make parsing harder, and give no benefit at all.
Cheers,
Andreas
news:alpine.BSF.2.00.1207221550590.17748@joyce.lan
>> For people with unique skills or knowledge, $800/hr is not unusual.
>> So long as the rate is published ahead of time, you're not going to
>> get much argument. ("Yes, we know it's high. But we've already told
>> you how to download stuff yourself for free.")
>
> Please note : out of pocket expenses (if someone has to travel to a
> hearing, say) would be reimbursed, but
> IETF volunteers will not be paid from these fees.
If you know, how often have people been deposed on behalf of the
IETF, and how long does it typically take?
My thought is that in a depo or trial, the other side pays both for the
expenses and the time of the person being deposed, so it would be good
idea to say up front here's what it'll cost if you want a live witness.
Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
news:65C49A3B-434A-4782-AFB9-FD940E3B12EA@nordu.net
fyi the applicability stmt version 00 was submitted by joe the other day.
19 jul 2012 kl. 13:19 skrev "Sam Hartman" <hartmans-ietf@mit.edu>:
>>>>>> "Stephen" == Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
>
> Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-)
>
> Stephen> If I put in an RFC editor note adding a normative reference
> Stephen> to the new EAP applicability statement [1] would that sort
> Stephen> this out and not cause any problems for anyone?
>
> I don't object to that, but it does hold up the doc. I'm happy letting
> this doc go forward now so long as we're all on the same page on the
> applicability stament. I realize we run the risk that somehow the
> applicability effort derails. Personally, I'm willing to take that
> risk, so long as we believe today we do intend to publish the
> applicability statement.
>
> If someone on the IESG or in the community wants that normative
> reference, I support adding it. I'm just not asking for it myself.
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab
news:1342921093.7688.90.camel@gwz-laptop
On Sat, 2012-07-21 at 13:25 -0700, Martin Thomson wrote:
> On 21 July 2012 06:55, Yoav Nir <ynir@checkpoint.com> wrote:
> > This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
>
> But moving it to the southern hemisphere would have.
How?
news:CAPv4CP95Rhma3reOvrWfrWQE_mqsyY8bL2EvkZq5hD6gbyf_ow@mail.gmail.com
On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> Hi All,
>
> I am working on an I-D which is intended as proposed standard but need
> some addition requirement language. Therefore, I want to propose to
> write a draft to update RFC2119 to add some other language requirement
> as below:
>
> IF x, THEN y:
>
> ELSE:
>
> ELSE IF:
>
> Please send your comments or advise, thanking you,
That doesn't have to be in 2119. Lots of RFCs have pseudocode at
various levels of rigor. Just look around at some protocol specs for
examples.
news:57D81A5A-B80B-4DC1-87FE-450E91A01A20@vigilsec.com
Joe:
I think you missed my point. In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier. I do not see a similar concept here.
Russ
On Jul 16, 2012, at 6:33 PM, Joe Abley wrote:
> Hi Russ,
>
> On 2012-07-15, at 11:39, Russ Housley wrote:
>
>> Peter:
>>
>> Thanks for the review. I've not read this document yet, but you review raises a question in my mind.
>>
>> If a DNSSEC policy or practice statement is revised or amended, what actions are needed make other aware of the change?
>
> Each DPS contains these kinds of details. Guidance for how to write the corresponding DPS sections is included in this draft:
>
> 4.2. Publication and repositories
>
> The component describes the requirements for an entity to publish
> information regarding its practices, public keys, the current status
> of such keys together with details relating to the repositories in
> which the information is held. This may include the responsibilities
> of publishing the DPS and of identifying documents that are not made
> publicly available owing to their sensitive nature, e.g. security
> controls, clearance procedures, or business information.
>
> 4.2.1. Repositories
>
> This subcomponent describes the repository mechanisms used for making
> information available to the stakeholders, and may include:
>
> o The locations of the repositories and the means by which they may
> be accessed;
>
> o An identification of the entity or entities that operate
> repositories, such as a zone operator or a TLD Manager;
>
> o Access control on published information objects.
>
> o Any notification services which may be subscribed to by the
> stakeholders;
>
>
> Joe
>
news:500A537E.7030505@cisco.com
I'd support a date change for IETF 95 but it should be the week of the
14th to take into account Palm Sunday and Good Friday. As to Ramadan, I
too would like to understand if there is a need to take this holiday
into account, and what would be the practical way to do that?
news:C023E9BE-5183-4A36-8470-B206FFBF1746@cdt.org
Hi Andreas,
On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
>> The first statement above gets at this, but it seems to me that the
>> middle ground between random generation per request and permanent
>> unique token is worth emphasizing if there will be proxies that want
>> to keep per-client identifiers around for some limited amount of time
>> that isn't forever.
>>
>> It's also worth noting that the second statement above is equally true for statically provisioned client IP addresses.
>>
>> Also, this statement in 8.3 is not really true and probably better left out:
>>
>> "Proxies using this extension will preserve the information of a
>> direct connection, which has an end-user privacy impact, if the end-
>> user or deployer does not know or expect that this is the case."
>>
>> There can certainly be a privacy impact whether the user or deployer has awareness/expectation or not.
>
> Can you give some proof or at least some arguments for this statement?
>
If the deployer has awareness/expectation but users do not, then users' expectations that their client addresses will not be shared will be violated.
But even if users have awareness/expectation that their client addresses will be shared, the implications of that sharing may not be obvious, and there is nothing preventing remote servers that receive the information from abusing it. Examples: a user who doesn't know that his address is static and can be used by a remote server to track and correlate all of his activity; a user who doesn't know that his ISP maintains records of customer identity tied to client addresses that may become subject to law enforcement request; a service that combines static addresses or tokens received via the header with other collected identifiers and shares them with other servers to enable more pervasive tracking.
The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.
Alissa
>
> Cheers,
> Andreas
news:CC3325CD.12C8B%d.malas@cablelabs.com
+1
On 7/23/12 6:28 AM, "DRAGE, Keith (Keith)"
<keith.drage@alcatel-lucent.com> wrote:
>Let's forget the religious discussion that seems to have broken out as a
>result of this.
>
>While Easter may be a major Christian festival, I don't believe the issue
>is such (I can think of no reasons why Christians would have a doctrinal
>reason other than those that apply to any other Sunday and those
>obligations could mostly be met at the venue rather than at home). Rather
>it is Easter the secular public holiday that happens to occur in many
>countries.
>
>This is the set of days when schools take an extended break, parents take
>said children off on short holidays; cheap air tickets cease to be
>available; when you get on the plane, it is full of screaming children;
>local transport all works to a reduced timetable; for those IETFers who
>end up wishing to travel by train, they find themselves moving to busses
>to cater for the engineering works which a 4 day weekend seems to
>encourage.
>
>So my advice would be, change the dates if it looks like you are going to
>hold the meeting in a country that takes such holidays, or where a
>significant number of people would need to transit through such a
>country. If so you need to take into account at least both the Friday and
>Monday in some countries.
>
>Keith
>
>P.S. Trying to avoid every religious and public holiday is an impossible
>task. Do what other organizations have done and concentrate on the impact
>of such holidays on holding the meeting in any location.
>
>> -----Original Message-----
>> From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
>> Behalf Of IETF Administrative Director
>> Sent: 20 July 2012 17:06
>> To: IETF Announcement List
>> Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org
>> Subject: Proposed IETF 95 Date Change
>>
>> The IAOC is seeking community feedback on a proposed date change for
>>IETF
>> 95
>> scheduled for March 2016.
>>
>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March
>>is
>> Easter.
>>
>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and
>> would like
>> feedback on those dates before making a decision. Comments appreciated
>>to
>> ietf@ietf.org
>> by 6 August 2012.
>>
>> Ray Pelletier
>> IETF Administrative Director
news:62E31CBF-190F-4FB3-94FC-1CEB318F6C84@gigix.net
On Jul 20, 2012, at 18:36 , Joel jaeggli wrote:
> On 7/20/12 09:06 , IETF Administrative Director wrote:
>> The IAOC is seeking community feedback on a proposed date change for IETF 95
>> scheduled for March 2016.
>>
>> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>>
>> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
>> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
>> by 6 August 2012.
>
> 20 march is palm sunday on the western calender.
>
> If one's a conflict presumably the other is too...
>
True, but if I can choose I would say 20-25 is better...
L.
>> Ray Pelletier
>> IETF Administrative Director
>>
>
news:3CAEDB8A-46A5-4055-B0F4-BC0984463866@vigilsec.com
Julian:
Do you object to http://www.ietf.org/tao-archive for the old version of the Tao?
Russ
On Jul 4, 2012, at 10:49 AM, Julian Reschke wrote:
> On 2012-06-21 23:08, Russ Housley wrote:
>> This URL <http://www.ietf.org/tao> will bring up the current document. It works exactly the same as <http://www.ietf.org/tao.html>.
>>
>> This means that <http://www.ietf.org/tao/archive> cannot be used as suggested on this thread.
> > ...
>
> Sorry?
news:500A572C.3020003@gmail.com
On 21/07/2012 02:30, Fred Baker (fred) wrote:
> On Jul 20, 2012, at 6:08 PM, Paul Hoffman wrote:
>
>> As for the Ramadan issue: we've had IETF meetings during Jewish holidays a few times, and folks dealt with it as best they can. If there are some accommodations that can be made at any IETF meeting for different holidays of major religions, I would bet that IETF Secretariat would be glad to hear them.
>
>
> It comes down to adding them to the clash list...
(which is at http://www.ietf.org/meeting/clash-list.html)
And we know that if we did that, on top of all the other technical meetings
that we have to avoid, the result would be overconstrained and scheduling
would become impossible. IMNSHO we need to treat all religious constraints
alike, and in practice that means ignoring them. For practical reasons, we
can't ignore major holidays - not because some of them are religious, but
because they block up hotels and airlines.
Finding the least bad solution is always going to be a compromise, and
I thank the IAOC for continuing to plan several years ahead.
Brian
news:4FFC6B72.2010401@viagenie.ca
On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
> I found the justification for REQ-6 hard to read/understand. Why does
> access to
> servers being on the internal network need to go through CGN at all?
Here's the thing: the server is not on the internal network. It's on the
external network, but it is still managed by the ISP. The ISP's network
includes the internal network and some part of the external network.
Furthermore, in many cases an ISP may run multiple CGNs, so the ISP's
network is actually multiple internal networks and some part of the
external network. The servers in the external network are operated by
the ISP and "know" the internal networks (have routes to them), and can
reach them directly without translation. And since connections from
subscribers to those servers may account for a lot of traffic, it is
important to not spend NAT resources on them.
Now, I'm not sure how to alter the existing text to make it easier to
understand. It seems to me that all the information is there, just not
with the same order/emphasis as what I wrote above. If the above was
useful for you to understand, could you please point out in the text
below what change would have helped you understand?
REQ-6: It MUST be possible to administratively turn off translation
for specific destination addresses and/or ports.
Justification: It is common for a CGN administrator to provide
access for subscribers to servers installed in the ISP's network,
in the external realm. When such a server is able to reach the
internal realm via normal routing (which is entirely controlled by
the ISP), translation is unneeded. In that case, the CGN may
forward packets without modification, thus acting like a plain
router. This may represent an important efficiency gain.
Figure 2 illustrates this use-case.
X1:x1 X1':x1' X2:x2
+---+from X1:x1 +---+from X1:x1 +---+
| C | to X2:x2 | | to X2:x2 | S |
| l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
| i | | G | | r |
| e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
| n |from X2:x2 | |from X2:x2 | e |
| t | to X1:x1 | | to X1:x1 | r |
+---+ +---+ +---+
Figure 2: CGN pass-through
Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:20120722014214.GK335@mip.aaaaa.org
Glen Zorn <glenzorn@gmail.com> wrote:
> On Sat, 2012-07-21 at 13:25 -0700, Martin Thomson wrote:
>
> > On 21 July 2012 06:55, Yoav Nir <ynir@checkpoint.com> wrote:
> > > This year Ramadan started yesterday, and ends on August 19. Moving the meeting one week in either direction would not have helped.
> >
> > But moving it to the southern hemisphere would have.
>
> How?
By cutting the sunrise-to-sunset fasting period of the day to a much
shorter period.
-- Cos
news:alpine.OSX.2.01.1207311615310.88195@173-11-110-132-sfba.hfc.comcastbusiness.net
One feature request that I discussed with Henrik was to either
"auto-detect" I-D file names and handle them slightly differently
from RFC numbers (by putting the file name as the final entry)
OR just having two tools. With the kind of feedback Henrik is
getting I am sure the tool will be improved/enhanced over time.
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 Mobile: +1 415-370-4628
E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
Skype: organdemo
news:CAHBU6isADXftAv91CCt-hxUabd6a++gPjuq7b4U4g_7HPsZ=Hg@mail.gmail.com
I have not been involved in the OAuth design processes, but for the
last few months, I’ve been a heavy user of production OAuth2 software.
Which I felt gave me a platform to comment on the issue:
http://www.tbray.org/ongoing/When/201x/2012/07/28/Oauth2-dead
-Tim
On Sun, Jul 29, 2012 at 2:57 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> It sounds indeed great to involve those communities that use the technology. However, I don't see an easy way to accomplish that when we talk about a really large community.
>
> For example, many people use TLS and they are not all in the TLS WG working group. I am not even talking about providing useful input to the work (since you would have to be a security expert and some people just want to get their application development done as quickly as possible). They just use the library.
>
> OAuth is a bit similar in that direction. Ideally, we want Web application developers to just use a library and then add their application specific technology on top of it rather than having to read the IETF specification and to write the OAuth code themselves.
>
> On Jul 29, 2012, at 2:13 PM, Worley, Dale R (Dale) wrote:
>
>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
>>>
>>> Eran claims that enterprise identity management equipment manufacturer dominate the discussion.
>>
>> There's a common problem in the IETF that the development of a standard is dominated by companies that incorporate the standard into their products, whereas the people who "really should" be involved in the development are those who will *use* the standard in operation.
>>
>> Dale
>
news:8D0D2246-86C9-4561-9EE9-3249DA7BAFF5@cs.columbia.edu
Also note that RFC 3924 exists.
On Jul 31, 2012, at 4:14 AM, Brian E Carpenter wrote:
> Loa,
>
> I can't speak for Scott, but I think the problem arises if any
> IANA assignments are needed, regardless of RFC status. That's
> because RFC 2804 speaks of "the process for creating and maintaining
> IETF standards." IANA assignments are part of standards maintenance
> (IMHO, of course).
>
> Don't forget that 2804 *also* says
>
> " - On the other hand, the IETF believes that mechanisms designed to
> facilitate or enable wiretapping, or methods of using other
> facilities for such purposes, should be openly described, so as to
> ensure the maximum review of the mechanisms and ensure that they
> adhere as closely as possible to their design constraints. The IETF
> believes that the publication of such mechanisms, and the
> publication of known weaknesses in such mechanisms, is a Good
> Thing."
>
> So it's a delicate balance.
>
> Brian
>
> On 31/07/2012 11:40, Loa Andersson wrote:
>> Scott,
>>
>> would you say that drafts aimed for experimental status are "standards
>> work".
>>
>> /Loa
>>
>> On 2012-07-30 18:33, Scott O Bradner wrote:
>>> 2804 does not say not to talk about such things - or that such
>>> documents should
>>> not be published as RFCs - 2804 says that the IETF will not do
>>> standards work
>>> in this area
>>>
>>> Scott
>>>
>>> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>>>
>>>> Under the long-standing IETF policy defined in RFC 2804, I trust
>>>> we will not be discussing this draft, or
>>>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>>>
>>>> Regards
>>>> Brian Carpenter
>>>>
>>>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>
>>>>>
>>>>> Title : Label-based Provider-Provisioned Lawful
>>>>> Intercept for L3 VPNs
>>>>> Author(s) : Shankar Raman
>>>>> Balaji Venkat Venkataswami
>>>>> Gaurav Raina
>>>>> Vasan Srini
>>>>> Bhargav Bhikkaji
>>>>> Filename :
>>>>> draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>>>> Pages : 12
>>>>> Date : 2012-07-30
>>>>>
>>>>> Abstract:
>>>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>>>> models like VPLS and the like do not have any provider provisioned
>>>>> methods of lawful intercept that are comprehensive, quick and
>>>>> easy to
>>>>> provision from one single point. More particularly the auto-
>>>>> provisioning of lawful intercept for all sets of streams travelling
>>>>> between VPN sites and consequent re-direction of these streams to
>>>>> the
>>>>> appropriate government network has not been covered without multiple
>>>>> instances of having to configure the intercept at various points in
>>>>> the network both in the Single-AS case and the Inter-Provider VPN
>>>>> case.
>>>>>
>>>>> this paper, we propose a technique which uses a set of pre-defined
>>>>> labels called Lawful Intercept labels and a method for provisioning
>>>>> lawful intercept amongst the various PE devices using these labels
>>>>> both in the Single-AS and the inter-provider VPN cases. A single
>>>>> point of configuration is the key to this idea. The intercepted
>>>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>>>> participating in the VPN. A technique called the Domino-effect
>>>>> provisioning of these Label-based Provider Provisioned Lawful
>>>>> Intercept mechanism is also outlined.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>>>
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>>>
>>>>>
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> I-D-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>
>>
>
--Steve Bellovin, https://www.cs.columbia.edu/~smb
news:D2FB5989-E220-4E00-A760-84C85C88A56E@hopcount.ca
On 2012-07-18, at 11:49, Russ Housley wrote:
> So a DNSSEC signer starts under one set of documents, and then for whatever reason, the policy changes and the parties validating the signature have no means to determine that the signer is following a new policy.
They have means, they just don't have a way of deriving a specific policy from a specific DNSKEY. The available means are documented in the DPS.
> So I am missing the value of the policy to the parties that rely on these signatures.
Your suggestion is that if there's no way to the policy just from the contents of a DNSKEY RR, there's no point publishing a policy at all?
Joe
news:500D3500.4080003@cs.tcd.ie
I'd encourage you to not try change 2119.
Instead, add whatever new definitions you feel
you need to your own draft that addresses some
technical, and not process, topic.
If people find your new definitions useful they'll
say and if enough of that happens they'll be
included in a 2119bis whenever that's done.
S.
On 07/23/2012 12:08 PM, Abdussalam Baryun wrote:
> Hi Stewart,
>
> Usually the (IF x, THEN y) means if x happens then y is a MUST, so I
> don't see the important reflection of a MUST in many documentation
> when using *if*. That is why I prefer to find requirements more easily
> while skimming any IETF document, the MUST, SHOULD, and IF, these are
> important requirement words in specifications. Please see below as
> examples per your requested.
>
> ------------------------------------------------------------------------------------------------------
> RFC4861>page36> IMO suggest to use IF, THEN
>
> If no entry exists, the sender creates one, sets its state
> to INCOMPLETE, initiates Address Resolution, and then queues the data
> packet pending completion of address resolution.
> ------------------------------------------------------------------------------------------------------
> RFC4861>page 49> IMO suggest to use IF and ELSE IF
>
> If the router already has a Neighbor Cache entry for the
> solicitation’s sender, the solicitation contains a Source Link-Layer
> Address option, and the received link-layer address differs from that
> already in the cache, then the link-layer address SHOULD be updated
> in the appropriate Neighbor Cache entry, and its reachability state
> MUST also be set to STALE. If there is no existing Neighbor Cache
> entry for the solicitation’s sender, the router creates one, installs
> the link- layer address and sets its reachability state to STALE as
> specified in Section 7.3.3. If there is no existing Neighbor Cache
> entry and no Source Link-Layer Address option was present in the
> solicitation, the router may respond with either a multicast or a
> unicast router advertisement. Whether or not a Source Link-Layer
> Address option is provided, if a Neighbor Cache entry for the
> solicitation’s sender exists (or is created) the entry’s IsRouter
> flag MUST be set to FALSE.
> ----------------------------------------------------------------------------------
> RFC5715>page 19>
>
> If R changes before T, then a loop will form
> around R, T, and S.
> -----------------------------------------------------------------------------------
> RFC6052> page 10> suggest delete *will* and to add as IF, THEN
>
> If a packet bound to
> 192.0.2.33 reaches the translator, the destination address will be
> translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
> routed towards R and then to A.
> -----------------------------------------------------------------------------------
>
> There are many examples that ignore the use of IF , THEN requirements,
> which I suggest to be in the I-D update of RFC2119 that I working on
> and will submit in 30 July,
>
> Regards
>
> Abdussalam Baryun
> University of Glamorgan, UK
> ==================================
>
>> Preferable with a list of RFC text snippets that would have been
>> more readable if these keywords had been used.
>
>> Stewart
>
>
>> On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
>> <abdussalambaryun@gmail.com> wrote:
>>> Hi All,
>>>
>>> I am working on an I-D which is intended as proposed standard but need
>>> some addition requirement language. Therefore, I want to propose to
>>> write a draft to update RFC2119 to add some other language requirement
>>> as below:
>>>
>>> IF x, THEN y:
>>>
>>> ELSE:
>>>
>>> ELSE IF:
>>>
>>> Please send your comments or advise, thanking you,
>>
>> That doesn't have to be in 2119. Lots of RFCs have pseudocode at
>> various levels of rigor. Just look around at some protocol specs for
>> examples.
>>
>
>
news:tsllii01d3t.fsf@mit.edu
I'd probably also recommend excluding paid employees of ISOC. I cannot
really think of rationale that applies to the secretariat staff but not
ISOC.
news:CD5674C3CD99574EBA7432465FC13C1B22726A0BCE@DC-US1MBEX4.global.avaya.com
> From: Yaron Sheffer [yaronf.ietf@gmail.com]
>
> [...] but what I'm reading is three concrete statements that IETF
> members can respond to, and (if we accept them as true) consider how
> to address in the future:
>
> - A Web-focused protocol was forced to adopt enterprise use cases.
> [...]
My first impulse is to say, yes, protocols that solve "enterprise"
problems are a lot more difficult than ones that solve individual-user
problems. One that showed up in my field (SIP) was the concept of
"securely" identifying the party you have called. If I normally call
John Smith at my bank to do business, and if John Smith is replaced at
his job by another person, and I call "John Smith at the bank", should
I authenticate that I am talking to John Smith, or should I
authenticate that I am talking to the person who holds the job at the
bank that John Smith used to have?
> Tim bray writes in an essay:
>
> Enterpriseyness · One of Eran’s central gripes is the immense
> difficulty of knitting "Enterprise" requirements into OAuth — or any
> other standards work, for that matter. He’s right. The Web use cases
> may not be easy to solve, but they’re easy to understand. [...]
>
> On the other hand, whenever I get into a conversation with someone on
> the Enterprise side, even when I think I understand the problem
> domain, I lose the plot, and fast. The requirements these people claim
> to have around both authentication and authorization are so arcane and
> subtle and legacy-laden that you have to be a full-time professional
> to even understand them.
Which reminds me that large organizations have the problem that every
new activity is necessarily a small change on a monstrous base of
current systems, and has to work harmoniously with them. As someone
once observed:
> The reason God could create the Universe in six days is that He didn't
> have to make it upward compatible.
Dale
news:510C5471-40D5-4B46-8AFA-680016021CDA@gmx.net
I certainly agree that the participation in the face-to-face meetings is indeed more costly. For leadership positions (as you call them) such participation is indeed important.
On Jul 29, 2012, at 2:02 PM, Glen Zorn wrote:
> On Sun, 2012-07-29 at 13:28 -0700, Hannes Tschofenig wrote:
>>
>> >
>> > Do you think that corporate domination of "open" standards development is OK?
>> >
>>
>> The barrier for participation is low since there are no membership fees, etc.
>
> For participation, yes, all that is needed is an email account; if one wishes to attend meetings (just the main ones - let's ignore interims), the bar rises considerably. The chances of dominating a WG or attaining a leadership position in the IETF are very close to zero without meeting attendance. I spend about 10% of my gross income on travel, meeting fees, etc. for IETF meetings; I don't consider that to be trivial.
>>
>> Nevertheless, those who participate in standardization efforts have to spend their time.
>
> And somebody's money: I spend about 10% of my gross income on travel, meeting fees, etc. for IETF meetings; I don't consider that to be trivial.
>
>> So, typically those who participate for a longer period of time need to have some incentives. These incentives often come from working for a specific company.
>>
>> We cannot force anyone to participate in any of our working groups. In the OAuth case we have lots of other people participating but they typically ask questions and provide implementation feedback rather than trying to steer the standardization work.
>>
>> Ciao
>> Hannes
>>
>> PS: Eran was also working for a big corporation, namely Yahoo. I could imagine that Yahoo also had some incentives to pay Eran for his participation in this work.
>
news:50186301.9030506@levkowetz.com
On 2012-07-31 14:35 Steven Bellovin said the following:
> There are a number of very weird entries that require special
> handling. I (also) wrote a Python script to convert the XML file to
> bibtex and had to deal with a number of these special cases. For
> example, RFC 4534 lists the authors as "A Colegrove, H Harney"
> instead of "A. Colegrove, H. Harney". Other names like "The Internet
> Society" require special handling. And I completely punted on proper
> capitalization of the titles; I just accept what's there.
Ah. I'll have to look at fixing cases like the ones you mention, then.
Thanks!
Henrik
>
> On Jul 31, 2012, at 2:23 PM, Ole Jacobsen wrote:
>
>>
>> Mehmet,
>>
>> The tool is not INTENDED to change the author order. A somewhat
>> incomplete database can indeed lead to unexpected results, use with
>> caution.
>>
>> Ole
>>
>> Ole J. Jacobsen
>> Editor and Publisher, The Internet Protocol Journal
>> Cisco Systems
>> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
>> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
>> Skype: organdemo
>>
>>
>> On Tue, 31 Jul 2012, Ersue, Mehmet (NSN - DE/Munich) wrote:
>>
>>> Nice tool.
>>>
>>> However, I am wondering why the tool changes the order of the names.
>>> There is actually a reason why documents list names in a specific order.
>>>
>>> Some of the citations appear to be incomplete, see RFC3410.
>>>
>>> Cheers,
>>> Mehmet
>>>
>>>
>>>> -----Original Message-----
>>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
>>> Of ext Ole
>>>> Jacobsen
>>>> Sent: Tuesday, July 31, 2012 11:17 AM
>>>> To: The IETF
>>>> Cc: RSOC; Heather Flanagan; rsag@rfc-editor.org
>>>> Subject: RFC and I-D Citation Tool
>>>>
>>>>
>>>> In The Internet Protocol Journal I have been using the following
>>>> citation format, best illustrated by an example:
>>>>
>>>> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
>>>> Berger, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched
>>>> Paths (LSPs)," RFC 6387, September 2011.
>>>>
>>>> So, that's full author names "and" before the last author name, title,
>>>> document number and date, using the American "quotation outside
>>>> punctuation rule."
>>>>
>>>> I got tired of doing this "by hand" so I asked Henrik if he could
>>>> write me a tool. He did (THANKS!), and the result is here:
>>>>
>>>> http://tools.ietf.org/tools/citation/
>>>>
>>>> This will take either the draft name or the RFC number as input and
>>>> produce a citation similar to the one above. You can of course play
>>>> with the elements and generate a format that suits your own taste, for
>>>> example, for I-Ds, in print it might be good to have the FILE NAME as
>>>> the last entry:
>>>>
>>>> Adam Langley, "Serializing DNS Records with DNSSEC Authentication,"
>>>> Internet Draft, work in progress, July 2011,
>>>> draft-agl-dane-serializechain-01
>>>>
>>>> ...since I like having filenames or URLs on one line (not wrapping)
>>>> as much as possible.
>>>>
>>>> Many thanks again to Henrik, and I hope you will find it useful too!
>>>>
>>>> Ole
>>>>
>>>>
>>>>
>>>> Ole J. Jacobsen
>>>> Editor and Publisher, The Internet Protocol Journal
>>>> Cisco Systems
>>>> Tel: +1 408-527-8972 Mobile: +1 415-370-4628
>>>> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj
>>>> Skype: organdemo
>>>
>>>
>>
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
news:E14BAB4D-5F34-4800-A660-29026D225EB5@cs.ucla.edu
On Jul 20, 2012, at 9:06 AM, IETF Administrative Director wrote:
> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like
> feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org
> by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
2016 is far away but UCLA has calendars that far out ;)
The new dates (20 - 25 March 2016) are much better, that is our spring break week.
Our spring 2016 teaching starts Monday 3/28/2016 (for all UC campuses except Berkeley, and perhaps other schools running quarter system), making it almost impossible to travel.
Lixia
news:6.2.5.6.2.20120717172251.09790e50@resistor.net
Hi Pete,
At 11:57 17-07-2012, Pete Resnick wrote:
>Perhaps I'm just being contrarian today, but I *do* think this
>document should be BCP and not Informational. It is not a
>requirements document in the sense that it is laying out
>requirements for future protocol documents being developed by a WG;
>it is a consensus document listing the requirements for the
>operation and administration of a type of device. If that doesn't
>fall within the 2nd paragraph of RFC 2026 section 5, I don't know what does.
I don't recall seeing an IPR disclosure on a BCP. Most new
Informational RFCs are also consensus documents. There are a few
Informational RFCs which lists requirements for operation and
administration. I don't think that this document should be BCP as
the status does not exercise the "must demonstrate at least two
independent, separate and successful uses of the licensing process".
Regards,
-sm
news:4FF891B7.1080504@viagenie.ca
On 07/03/12 05:51, Eggert, Lars wrote:
> On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
>> I found it is to be odd to have a requirements document as a BCP, but I am sure
>> you can sort the right status out with IESG.
>
> +1
>
> I fail to see why Informational wouldn't be the better status.
I don't care much about the status and will defer to the IESG, but I
thought Informational didn't mix well with 2119 language...
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:4FF44CA9.10702@bogus.com
On 7/4/12 06:52 , Russ Housley wrote:
> Mehmet:
>
> This is the price that NANOG charges for a table at their Beer-n-Gear
> event. I think that access to the IETF community is worth roughly
> the same price. We can reevaluate the price once there is feedback
> on the experiment. It might go up, It might go down.
NANOG is around 500 attendees. I daresay exposure to the average nanog
attendee is worth more, but ultimately the best feedback in that regard
will likely come from the sponsors.
> Russ
>
>
> On Jul 4, 2012, at 5:34 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:
>
>> Hi Russ, All,
>>
>> was there also a discussion on the contribution? $10**4 for two
>> hours chat with potential customers does not look very motivating.
>> As this is an experiment I would actually start with less obstacles
>> and see how it evolves.
>>
>> Cheers, Mehmet
>>
>>
>>> -----Original Message----- From: ietf-bounces@ietf.org
>>> [mailto:ietf-bounces@ietf.org] On Behalf
>> Of ext Russ
>>> Housley Sent: Thursday, June 28, 2012 8:41 PM To: Thomas Nadeau
>>> Cc: IETF discussion list Subject: Re: bits-n-bites: Exhibitors
>>> and product vendors hawking
>> wares at anIETF
>>> meeting?
>>>
>>> There was a long discussion about this event prior to it being
>> scheduled. Sorry you
>>> missed that discussion.
>>>
>>> We will have a discussion after the event to determine if we
>>> should do
>> it again.
>>>
>>> Russ
>>>
>>>
>>> On Jun 28, 2012, at 2:23 PM, Thomas Nadeau wrote:
>>>
>>>>
>>>> Has the IETF morphed into a conference/convention?
>>>>
>>>> http://www.ietf.org/meeting/84/bits-n-bites.html
>>>>
>>>>
>>
>
>
news:CADnDZ88OPjcqidmV+0cM4C0uhSxYL5u943TUePkZQohs8wp48A@mail.gmail.com
Hi John,
Let's wait for the iesg and I trust they will find the solution after
they read our comments. I beleive that your comments are sound, and
will be taken by the iesg. If things turn against your suggestions
there are some procedure-options to go forward, but I don't think will
be in that direction.
AB
On 7/6/12, John C Klensin <john-ietf@jck.com> wrote:
>
>
> --On Friday, July 06, 2012 07:16 +0200 Abdussalam Baryun
> <abdussalambaryun@gmail.com> wrote:
>
>> +1
>>
>> I support all your suggestions (i.e. point 1 and 2, and nits i
>> and ii ) , and hope that iesg, and editor agrees, and that the
>> community considers them for progress. I seen the change in the
>> draft-document-03 which I think getting better but still not
>> satisfied
>>
>> The new vesion 3 draft (dated 5 July) does not include all your
>> suggestion, please read and comment on draft-03 (the subject
>> refers to draft-02, did you read draft-03?).
>> http://tools.ietf.org/html/draft-hoffman-tao-as-web-page-03
>
> Abdussalam,
>
> Paul's note about draft 03 indicates that he posted it partially
> in response to my comments. Those comments were based on 02.
> >From my point of view, there is always a question about how much
> energy a document like this is worth: it is not normative or
> authoritative and, while I'd prefer to see it done differently
> (and said so in a follow-up note after skimming -03), I've got
> other IETF work to do and would prefer to see Paul and the IESG
> working on the Tao text itself rather than fine-tuning this
> document.
>
> I personally believe that the document could be further improved
> by moving it toward my earlier suggestions. I believe that
> more "what is this about" text belong in the Abstract and, in
> particular, that the relationship of the Tao (whether as an RFC
> or as a web page) deserves more explicit treatment than the
> second sentence of the Introduction. And I believe that forcing
> another RFC if details of the revision process are changed is a
> bad idea and so think that Section 2 (of -03) should talk about
> an initial procedure and/or in much more general terms but
> should then push details and changes off to the Tao itself
> (perhaps as an appendix). Ultimately, if we cannot trust the
> IESG and the Editor to be careful and sensible about this
> document, we are going to have problems that fine-tuning the RFC
> text can't prevent.
>
> But, if Paul and the IESG don't agree, I'm not convinced the
> subject justifies a lot more energy.
>
> best,
> john
>
>
news:20120722160435.68743.qmail@joyce.lan
> That said, moving the meeting further south would
> have helped as well vs. How far north Vancouver is.
Summer daytime temperatures in Vancouver are typically 20c or lower,
while in the southern US they're usually over 30c. I'm not sure
that would be an improvement.
You're not going to find cool temperatures again in July or August
unless you go as far south as Argentina or New Zealand.
R's,
John
news:0055B78D874058F9ECEC6E10@JcK-HP8200.jck.com
--On Thursday, July 05, 2012 14:19 -0700 Paul Hoffman
<paul.hoffman@vpnc.org> wrote:
> Based on many people's input (most recently, John's), I have
> updated the draft to more cleanly separate out the history of
> the Tao from the change that is happening.
Paul,
While I'd prefer to see you go even further in that direction
(e.g., incorporating more of the RFC 4677 Abstract in this
abstract, constructing things so that changes in the details of
editing procedures doesn't require a revised RFC), this version
is, IMO, greatly improved.
thanks
john
news:CAFCD98A-246D-482C-B8CD-6875D49ED94F@vpnc.org
On Jul 5, 2012, at 2:45 PM, Tony Hansen wrote:
> Is there going to be a way of seeing a list of all the versions of the tao? Or links within tao.html to the previous version? Perhaps a www.ietf.org/tao/ should be maintained that has pointers to all the versions as well any proposed update.
I think the Tao web page should point to RFC 4677 in a "well, how did I get here?" section, given that this is not the same as it ever was.
--Paul Hoffman
news:006801cd667a$d10b89d0$c801a8c0@computer
I have taken a look at this policy. but still not very clear about this
policy.
could you kindly show some examples for charging the fee?
Jiankang Yao
----- Original Message -----
From: "IETF Administrative Director" <iad@ietf.org>
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: <iaoc@ietf.org>; <iab@iab.org>; <ietf@ietf.org>; <wgchairs@ietf.org>
Sent: Friday, July 20, 2012 9:07 PM
Subject: Feedback Requested on Draft Fees Policy
The IAOC is seeking community feedback on a proposed policy by the IAOC to
impose
fees to produce information and authenticate documents in response to
subpoenas and
other legal requests.
The IETF receives requests for information, documentation, authentication or
other
matters through subpoenas and less formal means that require manpower and
materials
to be expended. These requests are on the rise. During the period 2005 to
2010 the IETF
responded to nine subpoenas. Since 2011 the IETF has received five
subpoenas and three
other legal requests for authenticated documents.
Each such request is time sensitive and involves the IETF Counsel, the IAD,
and members
of the IAOC, who together form the Legal Management Committee, to rapidly
analyze and
identify the means for satisfying the request. Often there is a need to
retain outside counsel,
especially in cases that might lead to depositions or court testimony.
The IAOC believes a Schedule of Fees is an appropriate and reasonable means
to recover
costs associated with such efforts.
The draft policy entitled Draft Fee Policy for Legal Requests can be found
at: <http://iaoc.ietf.org/policyandprocedures.html>
Before adopting a policy the IAOC would like feedback on this before making
a
decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
Ray Pelletier
IETF Administrative Director
news:CC2D8D42.8068%repenno@cisco.com
Good point, some data in this regards:
All previous behave RFCs that 'standardized' NAT behavior are BCPs
(RFC4787, 5508, etc).
And they are have lots of MUSTs
On 7/19/12 9:37 AM, "David Harrington" <ietfdbh@comcast.net> wrote:
>-- BCP or not? --
>
>As previously-responsible AD for behave, I have had serious concerns about
>this document being published as a BCP.
>
>
>In another email, I discussed whether PCP should be required to be
>compliant to this BCP.
>
>I think the IETF needs to decide whether lsn-requirements is something to
>be compliant to. The title and BCP status seem rather misleading, in my
>opinion.
>Following RFC3365, MUST is for implementers; SHOULD is for deployers. If
>we want to require vendors to implement specific features in a manner
>COMPLIANT to this specification, then this really should be a standard,
>not a BCP.
>If we want to standardize implementation behaviors, then I think this
>should be an explicit standard, not some other type of RFC that will
>implicitly be a standard but with possibly less scrutiny than an explicit
>standard would generate.
>
>
>A BCP often carries similar weight to a standard, and I question whether
>some of these requirements are best CURRENT practice, especially if PCP is
>a MUST. It might be best DESIRED practice, or best RECOMMENDED practice,
>but I doubt some of these requirements are best CURRENT practice. If we
>simply want to document what some existing deployments are doing, then I
>think an Applicability statement or an Informational RFC might be more
>appropriate than a BCP. I think this should be a BCP only if there is a
>strong consensus that this is the way deployments SHOULD be done, based on
>actual deployment experience by a variety of operators using current
>implementations - that would represent best CURRENT practices.
>
>
>--
>David Harrington
>Internet Engineering Task Force (IETF)
>Ietfdbh@comcast.net
>+1-603-828-1401
>
>
>
>
>
>On 7/19/12 8:51 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:
>
>>Behaviers, PCPers,
>>
>>During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was
>>filed regarding the PCP requirement. Details below.
>>
>>I think this DISCUSS needs to be discussed. So please discuss.
>>
>>Please reply to behave@ietf.org.
>>
>>Thanks,
>>Simon
>>
>>
>>-------- Message original --------
>>Sujet: Re: Martin Stiemerling's Discuss on
>>draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
>>Date : Thu, 19 Jul 2012 10:46:42 +0200
>>De : Martin Stiemerling <martin.stiemerling@neclab.eu>
>>Pour : Simon Perreault <simon.perreault@viagenie.ca>
>>Copie à : The IESG <iesg@ietf.org>, <behave-chairs@tools.ietf.org>,
>><draft-ietf-behave-lsn-requirements@tools.ietf.org>
>>
>>Hi Simon, all,
>>
>>On 07/17/2012 11:11 PM, Simon Perreault wrote:
>>> Le 2012-07-17 16:42, Martin Stiemerling a écrit :
>>>>> Each and every CGN MUST have PCP and MUST follow the constraints.
>>>>>I'll
>>>>> fix the text in a later revision.
>>>>
>>>> Can we mandate a specific protocol to be used for this or can we only
>>>> mandate that such a type of protocol is being used? I don't see the
>>>>IETF
>>>> in the position to mandate this type of protocol for CGNs.
>>>>
>>>> There are other protocols out there which might be suitable. Note that
>>>>I
>>>> am co-author of some, but this isn't the reason for the question. I do
>>>> not get any reward if I promote these protocols.
>>>>
>>>> It is more:
>>>> do we need to constrain CGN deployments to a protocol (PCP) which is
>>>> developed right now, or are we open to existing or future protocols,
>>>>or
>>>> whatever folks deploying this deem right?
>>>>
>>>> I would propose to change REQ-9 to :
>>>> REQ-9: A CGN MUST include a middlebox control protocol that allows
>>>> manipulation of CGN bindings with the following contstraints <list
>>>>items
>>>> A and B>
>>>> REQ-9a: If PCP is used these contstraints MUST be applied in addition
>>>>to
>>>> contraints A and B:
>>>> <list items C and D>
>>>
>>> That was discussed in IETF 81 (Québec). Here's the extract from the
>>> minutes:
>>>
>>> Stuart Cheshire: ietf has one port forwarding protocol,
>>>which
>>> is PCP, so we should require it by name
>>
>>There are multiple middlebox control protocols published by the IETF
>>(standards track and experimental) and I have not seen any call for
>>consensus on what **the** IETF's middlebox control is, neither I have
>>seen any RFC that states this.
>>
>>I do not see that an individual can declare IETF consensus based on his
>>own opinion.
>>
>>
>>>
>>> Dave Thaler: I agree. PCP doc is in final stages.
>>
>>Again, an opinion of an individual. Nothing wrong about it, but it does
>>not state IETF consensus.
>>
>>>
>>> There was consensus from the WG. In consequence, the text was changed
>>> from this (-02):
>>>
>>> A CGN SHOULD support a port forwarding protocol such as
>>>the
>>> Port Control Protocol [I-D.ietf-pcp-base].
>>>
>>> to this (-03):
>>>
>>> A CGN SHOULD include a Port Control Protocol server
>>> [I-D.ietf-pcp-base].
>>>
>>> (That requirement later became a MUST, but that's orthogonal to what
>>> protocol we require.)
>>
>>I do not see that the IETF can mandate what protocols are being used to
>>control a device. The market will decide!
>>
>>For instance, the is no MUST required that routers implement BGP. It is
>>good to do this, but if one decides to go for IS-IS (or whatever) that
>>is just fine.
>>
>>Another example, there is also no MUST requirement that routers, or
>>hosts in general, have to implement SNMP.
>>
>>However, I can see the immediate need to mandate that a CGN SHOULD/MUST
>>support a middlebox control protocol that is able to install and
>>maintain NAT bindings.
>>
>> Martin
>>
>>--
>>martin.stiemerling@neclab.eu
>>
>>NEC Laboratories Europe - Network Research Division NEC Europe Limited
>>Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>Registered in England 283
>>
>>
>>_______________________________________________
>>Behave mailing list
>>Behave@ietf.org
>>https://www.ietf.org/mailman/listinfo/behave
>
>
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave
news:4FF8A836.2090407@viagenie.ca
Wes,
Here's my take on this...
CGN as defined in this document does not only include NAT444. It is more
generic than that: it really means "multi-user NAT". Dave Thaler came up
with the example use case of the NAT in a wifi hotspot. It's just NAT44,
but it still fits with the draft's definition of CGN because you have
multiple users potentially fighting for the same NAT resources. Remember
that the main raison d'être of this draft is for the operator to be able
to ensure fairness between NAT users. So in this view I think it is
clearly behave material since the sunsetting of IPv4 really is
orthogonal to multi-user NATs.
On the question of IPv6: I don't think we should talk about IPv6 simply
because IPv6 NAT so far has not seen significant deployment in the
context of multi-user NAT. And NPTv6 is stateless so there are no
resources to fight for.
Back to your email, where you wrote:
> if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that.
How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"?
Thanks,
Simon
On 07/06/12 09:50, George, Wes wrote:
> I have a comment about this document related to some discussions that I've had with a number of ADs and WG chairs around the formation and charter of Sunset4 to determine what is and is not in scope for that WG.
>
> For a while both BEHAVE and Sunset4 had this document in their milestones, which clearly won't work. Therefore the distinction made between work to be done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically on the concept of NAT and the things necessary to make all flavors of it work, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, etc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only items. The BEHAVE chairs were represented in these discussions, and they believed that this document was in keeping with this distinction.
> In the document's introduction, for example, that generic nature is implied:
> "It is not an IETF endorsement
> of CGN or a real specification for CGN, but rather just a minimal set
> of requirements that will increase the likelihood of applications
> working across CGNs."
>
> However, this document states in section 2:
> "Note also that the CGN described in this document is IPv4-only.
> IPv6 address translation is not considered."
> I see that this is a new change to the -07 version, so I hate to rehash the discussion, but I think that this statement should be clearer.
> In reading the document, I don't believe that the intent was to limit it to being a discussion of NAT44[4], but that could be the way that this statement is interpreted. The distinction I might make to clarify is that since the document is talking about behaviors that are necessary to make IPv4 address-sharing work, it's specific to the IPv4 side of what could well be a dual-stack NAT, but it's not limited to simply NAT44[4].
>
> I'm not advocating pulling this document back so that it can go to the "right" working group, because I don't think that'll actually add any value to the document and I'm not a fan of process for process's sake. My concern is really more about content and naming- if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. If it's meant to be a generic LSN requirements doc, the authors should make the appropriate changes to keep it generic.
>
> Thanks,
>
> Wes George, at least partially wearing my Sunset4 chair hat
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
news:tsleho8j8wn.fsf@mit.edu
>>>>> "Stephen" == Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-)
Stephen> If I put in an RFC editor note adding a normative reference
Stephen> to the new EAP applicability statement [1] would that sort
Stephen> this out and not cause any problems for anyone?
I don't object to that, but it does hold up the doc. I'm happy letting
this doc go forward now so long as we're all on the same page on the
applicability stament. I realize we run the risk that somehow the
applicability effort derails. Personally, I'm willing to take that
risk, so long as we believe today we do intend to publish the
applicability statement.
If someone on the IESG or in the community wants that normative
reference, I support adding it. I'm just not asking for it myself.
news:CAMm+Lwg5YGiz+WCuTfM1Sv0DB9NSRvMr-YoLujCoBRrE8KQRbw@mail.gmail.com
There must be a cheaper way for NBC commentators to work out who Sir Tim
Berners-Lee is.
Perhaps we should have someone give an innane commentary...
On Tuesday, July 24, 2012, IETF Administrative Director wrote:
> The IAOC is pleased to announce the Co-Hosts for IETF 86 in Orlando
> Florida, USA
> March 10 - 15, 2013.
>
> The Co-Hosts are Comcast and NBCUniversal. Comcast Hosted IETF 71 in
> Philadelphia, is
> sponsoring IETF 85 in Atlanta, and has sponsored meeting breaks and ice
> cream socials at
> other meetings. <http://www.comcast.com>
>
> NBCUniversal is Hosting its first meeting with the IETF. <
> http://www.nbcuni.com/>
>
> We want to thank our benefactors. The IETF cannot support its technical
> standards efforts,
> including the Secretariat and RFC Editor, without the generous support of
> its hosts and
> sponsors.
>
> Interested in hosting or sponsoring an IETF meeting? Contact Drew
> Dvorshak at
> dvorshak@isoc.org <javascript:;>. The meeting schedule is here: <
> https://www.ietf.org/meeting/
> upcoming.html>
>
> Thanks again to Comcast and NBCUniversal!
>
> We are just days away from IETF 84 in Vancouver. Registrations are open
> and operators
> are standing by (so to speak). Visit <
> https://www.ietf.org/meeting/84/index.html> and join
> the 1,250 who have already registered.
>
> Ray Pelletier
> IETF Administrative Director
>
--
Website: http://hallambaker.com/
news:A4AF7C0C-B8FB-47CB-BF36-78F2686FA5E1@harvard.edu
great idea - just does not jive with the legal system which often need authenticated
copies of documents
Scott
On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
> > On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
> >> The draft policy entitled Draft Fee Policy for Legal Requests can be found
> >> at: <http://iaoc.ietf.org/policyandprocedures.html>
>
> Fine idea.
news:4FFB63AB.5020801@raszuk.net
Apologies if this is too simple question, but is there any tool for ipad
and/or android which would allow me to download for offline reading all
ietf/irtf drafts submitted between any two dates ?
Ideally it would be great to also be able to filter by version or by
string in the name to stay current on a given WG efforts or some
specific document.
Just checking for prior art before even considering doing it myself ;)
Many thx,
R.
news:20120710180729.42712860@hetzer
On Tue, 10 Jul 2012 10:54:53 -0400
Alissa Cooper <acooper@cdt.org> wrote:
> Hi Andreas,
>
> On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
> >> The first statement above gets at this, but it seems to me that the
> >> middle ground between random generation per request and permanent
> >> unique token is worth emphasizing if there will be proxies that want
> >> to keep per-client identifiers around for some limited amount of time
> >> that isn't forever.
> >>
> >> It's also worth noting that the second statement above is equally true for statically provisioned client IP addresses.
> >>
> >> Also, this statement in 8.3 is not really true and probably better left out:
> >>
> >> "Proxies using this extension will preserve the information of a
> >> direct connection, which has an end-user privacy impact, if the end-
> >> user or deployer does not know or expect that this is the case."
> >>
> >> There can certainly be a privacy impact whether the user or deployer has awareness/expectation or not.
> >
> > Can you give some proof or at least some arguments for this statement?
> >
>
> If the deployer has awareness/expectation but users do not, then users' expectations that their client addresses will not be shared will be violated.
I interpret the statement "which has an end-user privacy impact" to be
true if any of "end user" or "deployer" does not know about it.
So that should cover the case when the deployer knows, but not the end
user.
> But even if users have awareness/expectation that their client addresses will be shared, the implications of that sharing may not be obvious, and there is nothing preventing remote servers that receive the information from abusing it. Examples: a user who doesn't know that his address is static and can be used by a remote server to track and correlate all of his activity; a user who doesn't know that his ISP maintains records of customer identity tied to client addresses that may become subject to law enforcement request; a service that combines static addresses or tokens received via the header with other collected identifiers and shares them with other servers to enable more pervasive tracking.
Thanks for explaining.
Yes, I can agree on this.
I do not think that this header changes real life affect on end users
privacy very much, though.
The big issue here is that there is quite a lot of things that the end
user are aware of.
> The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.
See my answer to SM. I think it better explains that the expectations
of the end user are important to consider, even if these expectations
are wrong.
I don't think that text will have much impact on how the header field
is used in practice though, or any technical impact, so removing it is
fine with me.
It would be interesting to hear what Stephen Farrell thinks about it,
since he wrote that text.
Cheers,
Andreas
news:CAMm+Lwjv_x3qKW7xLQHpo24WQURrDqva2od+s1PmgxMW61t33A@mail.gmail.com
In theory yes, a signed document would be sufficient.
In practice it would then require an expert witness at $400/hr to
explain that it meant it was authentic.
The schedule of fees seems a reasonable response to a real cost being
imposed on the organization.
On Fri, Jul 20, 2012 at 10:25 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> [assuming you mean the "go look it up" idea]
>
> We have the technology. Surely a CMS signed object (or even just an HTTPS download) would provide adequate authentication that it came from the IETF. And it doesn't seem like we would have a problem providing authenticated documents to the world.
>
>
>
>
> On Jul 20, 2012, at 10:17 AM, Bradner, Scott wrote:
>
>> great idea - just does not jive with the legal system which often need authenticated
>> copies of documents
>>
>> Scott
>>
>> On Jul 20, 2012, at 10:14 AM, Scott Brim wrote:
>>
>>>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>>>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found
>>>>> at: <http://iaoc.ietf.org/policyandprocedures.html>
>>>
>>> Fine idea.
>>
>>
>>
>
--
Website: http://hallambaker.com/
news:225158E4-78BC-42BC-8339-EB9E0DE75AA7@sobco.com
2804 does not say not to talk about such things - or that such documents should
not be published as RFCs - 2804 says that the IETF will not do standards work
in this area
Scott
On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
> Under the long-standing IETF policy defined in RFC 2804, I trust
> we will not be discussing this draft, or
> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>
> Regards
> Brian Carpenter
>
> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>> Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
>> Author(s) : Shankar Raman
>> Balaji Venkat Venkataswami
>> Gaurav Raina
>> Vasan Srini
>> Bhargav Bhikkaji
>> Filename : draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>> Pages : 12
>> Date : 2012-07-30
>>
>> Abstract:
>> In models of Single-AS and inter-provider Multi- Protocol Label
>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>> models like VPLS and the like do not have any provider provisioned
>> methods of lawful intercept that are comprehensive, quick and easy to
>> provision from one single point. More particularly the auto-
>> provisioning of lawful intercept for all sets of streams travelling
>> between VPN sites and consequent re-direction of these streams to the
>> appropriate government network has not been covered without multiple
>> instances of having to configure the intercept at various points in
>> the network both in the Single-AS case and the Inter-Provider VPN
>> case.
>>
>> this paper, we propose a technique which uses a set of pre-defined
>> labels called Lawful Intercept labels and a method for provisioning
>> lawful intercept amongst the various PE devices using these labels
>> both in the Single-AS and the inter-provider VPN cases. A single
>> point of configuration is the key to this idea. The intercepted
>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>> participating in the VPN. A technique called the Domino-effect
>> provisioning of these Label-based Provider Provisioned Lawful
>> Intercept mechanism is also outlined.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
news:EF66243C-94EB-466E-8654-86032B14BC8B@gmx.net
I put a RTF version of the document here:
http://www.iab.org/wp-content/IAB-uploads/2012/07/IPv6-Privacy-Survey1.rtf
Does this work for you?
Ciao
Hannes
On Jul 24, 2012, at 10:06 AM, Stephane Bortzmeyer wrote:
> On Mon, Jul 23, 2012 at 09:24:56AM -0700,
> IAB Chair <iab-chair@iab.org> wrote
> a message of 95 lines which said:
>
>> those familiar with OS IPv6 implementations are asked to complete a
>> short survey
>> <http://www.iab.org/wp-content/IAB-uploads/2012/07/IPv6-Privacy-Survey.doc>
>
> Which RFC (or other open specification) describes the ".doc" format?
>
> And since when Microsoft software is required for IETF work?
>
> [Don't ask me to try LibreOffice, it runs at 100 % CPU time for
> *minutes* when opening this document.]
news:6EC0C8C6-3071-4DFD-8F4C-779A08D94D1E@gmx.net
>
> Do you think that corporate domination of "open" standards development is OK?
>
The barrier for participation is low since there are no membership fees, etc. Nevertheless, those who participate in standardization efforts have to spend their time. So, typically those who participate for a longer period of time need to have some incentives. These incentives often come from working for a specific company.
We cannot force anyone to participate in any of our working groups. In the OAuth case we have lots of other people participating but they typically ask questions and provide implementation feedback rather than trying to steer the standardization work.
Ciao
Hannes
PS: Eran was also working for a big corporation, namely Yahoo. I could imagine that Yahoo also had some incentives to pay Eran for his participation in this work.
news:EDC0A1AE77C57744B664A310A0B23AE240AE8B63@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com
Let's forget the religious discussion that seems to have broken out as a result of this.
While Easter may be a major Christian festival, I don't believe the issue is such (I can think of no reasons why Christians would have a doctrinal reason other than those that apply to any other Sunday and those obligations could mostly be met at the venue rather than at home). Rather it is Easter the secular public holiday that happens to occur in many countries.
This is the set of days when schools take an extended break, parents take said children off on short holidays; cheap air tickets cease to be available; when you get on the plane, it is full of screaming children; local transport all works to a reduced timetable; for those IETFers who end up wishing to travel by train, they find themselves moving to busses to cater for the engineering works which a 4 day weekend seems to encourage.
So my advice would be, change the dates if it looks like you are going to hold the meeting in a country that takes such holidays, or where a significant number of people would need to transit through such a country. If so you need to take into account at least both the Friday and Monday in some countries.
Keith
P.S. Trying to avoid every religious and public holiday is an impossible task. Do what other organizations have done and concentrate on the impact of such holidays on holding the meeting in any location.
> -----Original Message-----
> From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
> Behalf Of IETF Administrative Director
> Sent: 20 July 2012 17:06
> To: IETF Announcement List
> Cc: iaoc@ietf.org; iab@iab.org; ietf@ietf.org; wgchairs@ietf.org
> Subject: Proposed IETF 95 Date Change
>
> The IAOC is seeking community feedback on a proposed date change for IETF
> 95
> scheduled for March 2016.
>
> Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is
> Easter.
>
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and
> would like
> feedback on those dates before making a decision. Comments appreciated to
> ietf@ietf.org
> by 6 August 2012.
>
> Ray Pelletier
> IETF Administrative Director
news:500CFF8E.1090905@cisco.com
On 22/07/2012 17:26, Melinda Shore wrote:
> On 7/22/12 3:17 AM, Abdussalam Baryun wrote:
>> IF x, THEN y:
>>
>> ELSE:
>>
>> ELSE IF:
>>
>> Please send your comments or advise, thanking you,
>
> Yes: you might try to explain what problem you think you're
> solving.
>
> Melinda
>
>
Preferable with a list of RFC text snippets that would have been
more readable if these keywords had been used.
Stewart
news:500C30AA.80101@gmail.com
On 7/22/12 6:10 AM, Victor Kuarsingh wrote:
> It is my understanding that for these types of reasons (and others),
> folks who are adhering to Ramadan can eat while traveling and if they
> are sick.
I'd be a lot more comfortable with people describing/speaking up
for their own religious requirements.
> That said, moving the
> meeting further south would have helped as well vs. How far north
> Vancouver is.
I'm having to travel quite far south to get to Vancouver. That
participants are spattered across the planet is part of the
scheduling challenge.
Melinda
news:5017BDFE.5020100@gmail.com
Loa,
I can't speak for Scott, but I think the problem arises if any
IANA assignments are needed, regardless of RFC status. That's
because RFC 2804 speaks of "the process for creating and maintaining
IETF standards." IANA assignments are part of standards maintenance
(IMHO, of course).
Don't forget that 2804 *also* says
" - On the other hand, the IETF believes that mechanisms designed to
facilitate or enable wiretapping, or methods of using other
facilities for such purposes, should be openly described, so as to
ensure the maximum review of the mechanisms and ensure that they
adhere as closely as possible to their design constraints. The IETF
believes that the publication of such mechanisms, and the
publication of known weaknesses in such mechanisms, is a Good
Thing."
So it's a delicate balance.
Brian
On 31/07/2012 11:40, Loa Andersson wrote:
> Scott,
>
> would you say that drafts aimed for experimental status are "standards
> work".
>
> /Loa
>
> On 2012-07-30 18:33, Scott O Bradner wrote:
>> 2804 does not say not to talk about such things - or that such
>> documents should
>> not be published as RFCs - 2804 says that the IETF will not do
>> standards work
>> in this area
>>
>> Scott
>>
>> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>>
>>> Under the long-standing IETF policy defined in RFC 2804, I trust
>>> we will not be discussing this draft, or
>>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>>
>>> Regards
>>> Brian Carpenter
>>>
>>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>>
>>>> Title : Label-based Provider-Provisioned Lawful
>>>> Intercept for L3 VPNs
>>>> Author(s) : Shankar Raman
>>>> Balaji Venkat Venkataswami
>>>> Gaurav Raina
>>>> Vasan Srini
>>>> Bhargav Bhikkaji
>>>> Filename :
>>>> draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>>> Pages : 12
>>>> Date : 2012-07-30
>>>>
>>>> Abstract:
>>>> In models of Single-AS and inter-provider Multi- Protocol Label
>>>> Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>>> Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>>> models like VPLS and the like do not have any provider provisioned
>>>> methods of lawful intercept that are comprehensive, quick and
>>>> easy to
>>>> provision from one single point. More particularly the auto-
>>>> provisioning of lawful intercept for all sets of streams travelling
>>>> between VPN sites and consequent re-direction of these streams to
>>>> the
>>>> appropriate government network has not been covered without multiple
>>>> instances of having to configure the intercept at various points in
>>>> the network both in the Single-AS case and the Inter-Provider VPN
>>>> case.
>>>>
>>>> this paper, we propose a technique which uses a set of pre-defined
>>>> labels called Lawful Intercept labels and a method for provisioning
>>>> lawful intercept amongst the various PE devices using these labels
>>>> both in the Single-AS and the inter-provider VPN cases. A single
>>>> point of configuration is the key to this idea. The intercepted
>>>> traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>>> participating in the VPN. A technique called the Domino-effect
>>>> provisioning of these Label-based Provider Provisioned Lawful
>>>> Intercept mechanism is also outlined.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>>
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>>
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>
>
news:500EA01C.8060504@viagenie.ca
Le 2012-07-24 03:06, Stephane Bortzmeyer a écrit :
> And since when Microsoft software is required for IETF work?
Even though I replied to the survey, this also irritated me. And I sense
a trend here. It seems that the number of non-plain-text files coming
from IAB has been increasing.
Suggestion: just put the content right in the body of the email. I see
no need for any kind of attachment.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca