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:
> . . . . . . . .. . . . .
> . . . . . . ..
>
> . . . . . . . ..
> . . . . . . . .
> . .. .. . . .
> . .. .. . . .
>
> . . . . . . . . .. . . . .
> . .. .. . .. ...
>
> . . . . . . . ..
> . . . . . . . .
> . .. .. . . .
> . .. .. . . .
> . .. .. . . .
>
> . . . . . ..
> . . . . ... .
> . . . . . . ... . .. ... .
> . . ..
>
> . . . . . . . . . . ..
> . . .
> . . . .
>
> .. ..
>
> .
>
>> .. .......
>> .. .
>> .. . . . . . . . . . . . .
>> . .. .....
>> . .. . .
>> . . .. .
>> .. .........................
>> .. ...................
>> .. .....................
>>
>>
>> ..
>> . . . . .. .. . . . . . ..
>> . . . . . . . ... . .
>> . . . . . . .. . . . . .
>> . . . .. . . . . . . ..
>> . . . . . . . .. ... .
>> . . . ..
news:50180A18.2090008@bogus.com
On 7/31/12 9:15 AM, Randy Bush wrote:
>> ... . . . . . . . .. . .
>> . . . . . . . . . . .
>> . ..
> . . . . . . . . . . . . ..
> . . . . ... . . . . ... . . . .
> ..
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.
> .
>
news:6.2.5.6.2.20120710081323.08c9bcf8@resistor.net
Hi Andreas.
At 04:28 10-07-2012, Andreas Petersson wrote:
>. . . . . . ..
>. . . . . . . . . . . .
>. . . ..
>. . . . . .. . . . . . . . .
>. . . ....
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
>. . . . . . .. . . . . . ..
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:
> . ..
>
> . ..... .... . . ..
>>
>> . . ..
>>
>> . ..... ... .. .. .. .. ..
>>> . . . . .. ... . . .. . ... . .
>>> . . . . .. . . . . .
>>> . ..... . . .. . . .... . .. . .
>>> . . . ... . . . .. . .
>>> . . . . . . ..
>>
>> .. . . . . . ... . . . . .
>> . . . . ..
>
> . . . . . . . . . .. . .. .
> . . . . . . . . . . . . .. .
> . . . . . . . ..
I agree this has been harder than it ought have been for some
reason. I guess that just happens sometimes.
>
>> .. . . . . . .
>> . .. . .. .. ... . .. . ... .
>> ...
>>
>> . . . . . . . .. . . ....
>>
>> . . . . . . . . . .. . ..
>
> . . ... . . . . . . . . .. . .
> . . . . . . . . . . . . .
> . . . . . . ....
Well, you seemed motivated:-)
> .. . . . ..
>
> . . . .. . .. . . . ... . .
> . .. . .. . . .. . . . . . . .
> .. .. . ...
>
> . . . .. . .. .
> ... . . . . . .. .... . . .
> .. .. . . . . . ... .
> .. . . . . . . . .. .. .
> . . ....
>
> . . . . . . . . .... .. . ..
> . . ..
>
> . . . . . . . . . . . . ..
> . . . . . . . . . . . . ..
> .... . . .. . . .. . . . . ..
>
> . . ..... . . . . . ... . .. . .
> . . . . ...
>
> . . . . . . . . .. . . . . ..
> . . . . .... . . . . . .. .
> .. ... . . . . ..
>
> . . . . .. . .... . . . .. .
> .. . . .. .. ...
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'. . . . .... . . . . ..... .
> . . . . . . .. ....
> ................... . .
> ....... . . . . . .
> . . . . ...
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 . . ... . . . . .
> .. . . . . . . . .. .. . . . .
> . . . ...
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.
>
>
> .. ..
>
>
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:
>> .. . . . . . . . . . . . .
>> . . .. . . . . . . .
>> . . . .. ... .. . . .. . ..
>> . . . . . .. . ... ..
>
> ... . . . . . . . . . . . . . .
> .. . . . . . . . . . . . . .
> . ..
>
> . . . . . . .. .... . . ..
> . . . . . . . . . .. ... . . .
> . . .. .... . . ... .. . ... . .
> . . . . . . . ....
>
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
> ....
> .
news:CF472A8775DF4CDEEA6A1325@JcK-HP8200.jck.com
--On Friday, July 20, 2012 06:07 -0700 IETF Administrative
Director <iad@ietf.org> wrote:
> . . . . . . . . . . .
> . . . . . . . . .
> . . . . . . . .
> . ..
>...
> . . . . . . . . . . .
> . . . .. . . .
> ..... . . . ..
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:
> . . . . . . . .. . . . .
> . . . . . . ..
>...
> This draft also . . . . . .
> paid employees.
> . . Secretariat
> . . 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
. 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 . 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:
> . . . . . . . . . . . . . . .
> . . . . . . . . . . . .
> . . ..
>
> . . . . . .. .. . . .
> . . . . . . . . . . . .
> . . .. . . . . . .. . . . . . . . .
> . . . .. . . . . . . . . . .
> . . . . . ..
>
> . . . . . . . . . . .. . .. . .
> . . .. . . . . . . .. . . . .
> . . . . . . .. . . . . . . . . ..
> . . . . . . . . . . ..
>
> . . . . . . . . . . . . . . .
> . . . . ..
>
> . . . . . . . . . . . . .
> .. ..............>
>
> . . . . . . . . . . . . . .
> .. . . . ..... . . . ..
>
> . .
> . . .
news:7CB6858E-9F28-4BA7-8683-3903F521C2A0@checkpoint.com
. Jul 20, 2012, at 4:52 PM, Worley, Dale R (Dale) wrote:
> On .. ..... . ... ... . . . ..
>> . . . . . . . . . . . . .
>> .. ..............>
>
> . . . . . . . . . . . . . .
> . . . . .. . . . . . . ..
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:
> >> . . . . . ... ..
>
> .> . . ..... . . . . . . . .
> .> . . . . .. . . . .. ... . . .
> .> . . . . . ..
>
> . ... . . . . . ... . . . . .
> .. ...
> . . . . ... . . . . . . . .
> . . . . . . . . . . .
> . . ..
> ... . . . .. . . . . . . .
> . . ... ...
> . .. . . . . . . . . . .
> . ...
> . . . . . . . . . .
> . . . . ....
Makes sense to me.
> >> . . . . . . ..
> >> . . . . . . . . . .. . . .
> >> . . . . . . . ..
> >>
> >> . . . . . . . . . .. . .
> >> .. . . . . . . . . . . . .
> >> . . . ..
>
> .> . . . . . . . . .. . .. ... .
> .> . . . .... . . . . . . . . ...
> .> ....
>
> . . . . . . . .. ... . . . . .
> . . . . . . . .. . . .
> . . . . . .. . . . . .
> . . . . . . . . ..
> . . . . . ... .. . . . . . . . .
> . . . . . . . . . . .
> . . ..
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:
> . .. . ..
>
> . . . . ... . .. . . . . . . . .. . . . . . . . . . . . .. . . ... . . .. . .. . . . . . . . . .. . . .. . . . . ... . . . . ... .. . . . . ... . ..
>
> .. . .
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
news:20120704184933.79868.qmail@joyce.lan
>. . . . .. . . . . . . .
>. . . .. . . . . . . . .
>. . . . . ..
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
. 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
... .. . .. . ... .. . . .
......> ..
> . . . . . . . . . . . .
>. . . . . . . . . .
>. . . . . . . ..
>...
> . . . . . . . . . . . .
>. . .. . . . ..... . . .
>..
. . .. . . . . . . . .
. .. . . . . . . . . . . . . . . .
. . . . . . . . . ..
.
news:50107D3E.2030902@mulligan.com
And I could possibly use a room for Thursday night...
. 07/25/2012 05:06 PM, Dave Crocker wrote:
>
>
> On ..... ... .. . . ..
>> . . . . . . . . . . . .. .. . .
>> . . .. . . . .. . . . . . ..
>
>
> . . . . . . . .. . . . . . ..
>
> ..
news:m2mx2tsazr.wl%randy@psg.com
> . . . . .
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
> .. . . . . . . . . . . . .
> . . .. . . . . . . .
> . . . .. ... .. . . .. . ..
> . . . . . .. . ... ..
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
. 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 . free.")
R's,
John
news:65992FFB-CEE6-4D0A-B6EC-9379063F4FAC@checkpoint.com
On Jul 21, 2012, at 10:00 AM, Eliot Lear wrote:
> ... . . . . . . . . . . . . . . .
> . . . . . . . . . .. . . .. .
> . . . . . . . . . . . . . .
> . .. . . . . . . . . . ..
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> ..
> . ... . . . .. . . ... . .
> . . . . . . .. . . . .
> . . . . . . . . . .
> . . . . . . . .
> . .. . . . . . . . . .
> . . . . . . . . .. . .
> ... . . . . . . . . . .. .
> ... . . ..
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:
>. .. . . ..
>..............>
outstanding - now we can't meet that whole year... ;-)
>. . .. .. . ... .. . .. . ..
>
> > . . . . ... . . . . . . . . . . . .
> > . . . . . . . . ..
> >
> > ..
> > .
> >
> > . .. . .. . . ... .. . . ... ......> ..
> >>
> >> . . .. .. . ... .. . . ..
> >>
> >>> . ..... ... . . . . ..
> >>>> . . . . . . . . . .
> . . . .
> >>>> . . . ..
> >>>>
> >>>> . . . . . . . . . . .
> .. . . . ..
> >>>>
> >>>> . . . . . . . . . . . . .
> . . . .
> >>>> . . . . . . . .. .
> . . .....
> >>>> . . . ..
> >>>
> >>> . . . . . . . . ..
> >>>
> >>> . ... . . . . . . ....
> >>
> >> . . . . . . . . .. . .
> . . . . . . ..
> >>
> >> .. . . . . .. . . . . . . .
> . .. . . .. .. . . . .. .
> . .. . . . . . . . . ..
> . . . . . ..
> >>
> >> . .. . . . . . . . ..
news:alpine.BSF.2.00.1207221654200.31418@joyce.lan
> . . . . . . . . . . . . . . .. . . . . . ..
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
> > ... . . . . . . . .. . .
> > . . . . . . . . . . .
> > . ..
> . . . . . . . . . . . . ..
> . . . . ... . . . . ... . . . .
> ..
+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
..
> .. . . . . . . ... . . ... . . ..............>.
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:
> . . . . . . ..
>
> . . . . . . . . . . . .
> .. . . . . . ..
Gotta be!
>
> .
>
> . ..... ... .. . . . ..
> > .. .. . . .. . . . . ..
> >
> > .
> >
> > . ..... .... . . . ..
> >> . . . . . . . . . . . . . . . .
> >> . . . . . . . . . . . . . . . .
> >> . . .
> >>
> >> .
> >>
> >> . . .. .. . ... .. . . . ..
> >>
> >>> . . ... . . . . . .. . .
> >>> . . . . . . .. .
> >>> ................ . . ..
> >>>
> >>> .
> >>> . .
> >>>
> >>> . ..... .... ....... ..
> >>>> . . ... . . . . ... ... ..
> >>>>
> >>>>
> >>>> . . ... ... . . . . .
> >>>> .... . . .
> >>>> . . .
> >>>> . .
> >>>> . .
> >>>> . .
> >>>> . . ...................
> >>>> . . .
> >>>> . . .....
> >>>>
> >>>> ..
> >>>> . . . ... . ... .. . .
> >>>> . ... . . . . ... .
> >>>> . . . . .. . .. ... . . .
> >>>> . . . . . . . . . . . .
> >>>> . . . . . . .. . . . .
> >>>> . . . . .. . . . ..
> >>>> . . . . . . . . . .
> >>>> . . . . . ... . . . . .
> >>>> . . . . . . . . .
> >>>> . . . . . . . . . . .
> >>>> . . . . . ... . . . ... .
> >>>> ..
> >>>>
> >>>> . .. . . . . . . . . . ...
> >>>> . . . . . . . . . .
> >>>> . . . . . . . . . .
> >>>> . . . ... . . ... . .. . .
> >>>> . . . . . . . . .. . .
> >>>> . . . . . . . . . . . . . . . . .
> >>>> . . . .. . . . . ...
> >>>> . . . ... . . .
> >>>> . . . . ..
> >>>>
> >>>>
> >>>> . . . . . . . . ..
> >>>> ...........................
> >>>>
> >>>> ... . . . . . ..
> >>>> .............................
> >>>>
> >>>>
> >>>> ... . . . . . . ..
> >>>> ..............
> >>>>
> >>>> .
> >>>> ..... . .
> >>>> .........
> >>>> ...................
> >>>> ... .. .............
> >>>> . .................
> >>>>
> >>
> >>
> >
> >
news:1095943C-3926-4697-AF13-C4C4D7A5505E@cisco.com
. . .. .. . 6.08 PM. Paul Hoffman ..
> . . . . .. ... . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . ..
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:
> . . . . . .. . . .. . . . . . . .. . . . . . . .. . . . . . . . ..
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:
> .. .. . . .. . . . . ..
>
> .
>
> . ..... .... . . . ..
>> . . . . . . . . . . . . . . . .
>> . . . . . . . . . . . . . . . .
>> . . .
>>
>> .
>>
>> . . .. .. . ... .. . . . ..
>>
>>> . . ... . . . . . .. . .
>>> . . . . . . .. .
>>> ................ . . ..
>>>
>>> .
>>> . .
>>>
>>> . ..... .... ....... ..
>>>> . . ... . . . . ... ... ..
>>>>
>>>>
>>>> . . ... ... . . . . .
>>>> .... . . .
>>>> . . .
>>>> . .
>>>> . .
>>>> . .
>>>> . . ...................
>>>> . . .
>>>> . . .....
>>>>
>>>> ..
>>>> . . . ... . ... .. . .
>>>> . ... . . . . ... .
>>>> . . . . .. . .. ... . . .
>>>> . . . . . . . . . . . .
>>>> . . . . . . .. . . . .
>>>> . . . . .. . . . ..
>>>> . . . . . . . . . .
>>>> . . . . . ... . . . . .
>>>> . . . . . . . . .
>>>> . . . . . . . . . . .
>>>> . . . . . ... . . . ... .
>>>> ..
>>>>
>>>> . .. . . . . . . . . . ...
>>>> . . . . . . . . . .
>>>> . . . . . . . . . .
>>>> . . . ... . . ... . .. . .
>>>> . . . . . . . . .. . .
>>>> . . . . . . . . . . . . . . . . .
>>>> . . . .. . . . . ...
>>>> . . . ... . . .
>>>> . . . . ..
>>>>
>>>>
>>>> . . . . . . . . ..
>>>> ...........................
>>>>
>>>> ... . . . . . ..
>>>> .............................
>>>>
>>>>
>>>> ... . . . . . . ..
>>>> ..............
>>>>
>>>> .
>>>> ..... . .
>>>> .........
>>>> ...................
>>>> ... .. .............
>>>> . .................
>>>>
>>
>>
>
>
news:C8AEF564-5BAE-447B-9DBD-41192D1C0407@checkpoint.com
On Jul 22, 2012, at 4:42 AM, Ofer Inbar wrote:
> . . ......> ..
>> . .. ..... . ... ... . . ..
>>
>>> . . . . .... . . ......> ..
>>>> . . . . .. . . . . .. . . . . . . . . . . . ..
>>>
>>> . . . . . . . . ..
>>
>> ..
>
> . . . ..... . . . . . . . .
> . ..
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:
> . . . . . . .. . . . .. . . .
> . . .. . . . . . . ..... . .
> . . . . ..
>
> .. . . . . . . . . . . .. . .
> . . . . . . ..
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 ..... .... . . . ..
> > . . . . . . . . . . . . . .
> > . . . ..
> >
> > . . . . . . . . . . . .. . . . ..
> >
> > . . . . . . . . . . . . . . . . .
> > . . . . . . . .. . . . .....
> > . . . ..
> >
> > . .
> > . . .
>
> . . . . .. . ... . . . . . . . ..
> . . . . . .. . . . . . . ..
> . . . . .. . . . . . . ..
>
> . . . . . . . . . . . .. . . .
> . . . . . . . . . . ... .. . . . .
> ... ..
I agree, and prefer the former.
>
> Henk
>
>
>
news:m21ukr152m.wl%randy@psg.com
> . . . . . . . . . . . .
.aol>
. . . when . 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:
>
> . . .. .. . ... .. . . ..
>
>> . ..... ... . . . . ..
>>> . . . . . . . . . . . . . .
>>> . . . ..
>>>
>>> . . . . . . . . . . . .. . . . ..
>>>
>>> . . . . . . . . . . . . . . . . .
>>> . . . . . . . .. . . . .....
>>> . . . ..
>>
>> . . . . . . . . ..
>>
>> . ... . . . . . . ....
>
> . . . . . . . . .. . . . . . . . . ..
>
> .. . . . . .. . . . . . . . . .. . . .. .. . . . .. . . .. . . . . . . . . .. . . . . . ..
>
> . .. . . . . . . . ..
news:50096DA3.6080800@gmail.com
On 20/07/2012 14:07, IETF Administrative Director wrote:
> . . . . . . . . . . . . . . .
> . . . . . . . . . . . .
> . . ..
Do it. This will dissuade trivial requests and will be a drop in the ocean
. . . 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:
>>> . . . . . . .. .... . . ..
>>> . . . . . . . . . .. ... . . .
>>> . . .. .... . . ... .. . ... . .
>>> . . . . . . . ....
>>
>> . . . . . . . .. . . . . . .
>> .. .. . . .. .
>> . . . . . . . . ..
>
> . . .. . . . . . . . . . .
> .. . . . . . . ..
>
> . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . ... . ... . . . . . . ..
>
> ..
> . .. ...... . .. . .
> .. . . ... . .. ..
news:500D5C73.4000607@dcrocker.net
On 7/23/2012 4:26 AM, Stephen Farrell wrote:
> ... . . . . . . ..
>
> .. . . . . . .
> . . . . . . . . .
> .. . . .. ..
>
> . . . . . . . ...
> . . . . . . . ... .
> . . . . . ... ..
+1
d.
..
Dave Crocker
Brandenburg InternetWorking
bbiw.net
news:CD5674C3CD99574EBA7432465FC13C1B22726A0BCA@DC-US1MBEX4.global.avaya.com
> From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
>
> . . . . . . . . . . ..
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 . . recipients list...)
Sam,
Thanks . . review. comments inline...
On 07/10/2012 02:16 PM, Sam Hartman wrote:
> . . . . . . . ... .. . . .
> . . . . . . . . . . . . . . . .
> .. . .
> . . . . . . . ... .. . . ..
> . ........ . . . . . . . . .
> . ... . . . . . . . . .
> . . . .. . . . . . . . . . .
> . . . . . . . . . ...
> . .. . . . . . . . . . .
> . ..
>
> . . . . . . . . . . . .. . .
> . . . . . . . . . . . . .
> . . .. . . . . . . . . . .
> . . . .. . . . . . . . .
> . . . . . . . . .. . . .
> . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . . . .
> . . . .. . . . . . . . . .
> . . . . . . . . . . .. .
> . . . . . . . ..
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)
> . . . . . ... ..
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?
> . . . . . . . .
> . . . . . . . .
> ... . .. . . . . . . . . .
> .. . . . . . . . . .
> . . ... . . . .. . ... .
> ............ . .. . . . . . . . .
> .. . . . . . . . . .
> . ..... . . . ..
>
> .. . . . . . . . . . . .
> . . . . . . .. . . .
> . . . . . . . . .. .
> . . . . . . . . . . . . .
> . . .. . . . . . . . .
> . . . . . . . . . . . .
> . . ... .. . . . . . . .
> . . . . . . .. . . . . . .
> . . .. . ... . . .
> . .. . . . ... . . . .
> . . ..
Thanks for the full requirements text and justification. That going to
make my editing just so much easier!
> . . . . . . ..
> . . . . . . . . . .. . . .
> . . . . . . . ..
>
> . . . . . . . . . .. . .
> .. . . . . . . . . . . . .
> . . . ..
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
> . . . . . . .
> . . . . . . . .... . .
> . . . . . . . . . . .
> . .. . . . . . . . . . . ..
> . . . . . . . . . . . .
> . . . . . . . . . .. .. .
> . . . . . . . . ..
>
> . . . . . . . . . . . .
> . . . . . . . . .. .
> . . . . . . . . . .
> . .. . . . . . . . . .
> . . ..
--
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:
> ..
>
>> .. . . . . . . ... . . ... . . ..............>.
> . . . . . . . ........... . . . . . . . . . . . . ..
>
> .
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
. . . . . . . . . . . . . .
. . . ..
. . . . . . . . . . . .. . . . ..
. . . . . . . . . . . . . . . . .
. . . . . . . .. . . . .....
. . . ..
. .
. . .
news:337C9F850CBEA220D0A03ED3@JcK-HP8200.jck.com
--On Friday, July 06, 2012 07:16 +0200 Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> +.
>
> . . . . . ..... . . . .. . . .
> . . . . . . . .. . . .. . . .
> . . . . .. . . . . . .
> ..... . . . . . . . .
> .
>
> . . . . . .. . .. . . . . .
> .. . . . . . ... .. .
> . . .... . . . ......
> .........................
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.
.
news:4FFAF400.1030201@viagenie.ca
On ..07.09 11.03. George. Wes wrote:
> . . . . . .
> . . . . . . . .. . . . . ...
> . . . . . . . . ... .... .
> . . . . . . . . . . . .
> . . . . . . . . . .. . .
> . . .. ..
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.
>> . . .. . . . . . .
>> .....
> ... . .. . . . . . .
> . . . . . . .. . . . .
> . ... ... . . . . . . . ....
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 :
>
> . . . . . . . . . . .
> . .. . . . . ..
>
> . .. . .. . .. . .. . .
> .. .. . . . . .
> . ..... . .. . ..
>
> .. ... . . . ... . . . . .. ..
> . . . .. . . . .. .
> . ...
>
> . . . . . . .. .. . . . . . . .
> . . . .. . . ..... . . . . ..
>
> ..............
>
> . . . . . . . . . . . . . .
> . . . . . . . .. . . . . .
> . . . . . . . . . . . .. .
> .. . .... . . . . . . . . . . . .
> . . ..
>
> . .. .. . . . . ...
> . .. . . .. . ..
> .........
>
> .... . . . . . . . . . .. ..
> . . . ..
>
> . . . . .. . . . . . . . . ..
>
> .
>
>
>
> . .. .
> . . .. . . . .
> . .
> .. .. ..... .. .. .....
> .... ..... .. ...........
> .. .
news:tsl1ukj9ye1.fsf@mit.edu
>>>>> "Simon" == Simon Perreault <simon.perreault@viagenie.ca> writes:
Simon> . . . . . . . . . . . . .
Simon> . . . . . . . ...
OK.
>> . . . . . ... ..
Simon> . . ..... . . . . . . . .
Simon> . . . . .. . . . .. ... . . .
Simon> . . . . . ..
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
. 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 . . in 13.1.
>> . . . . . . ..
>> . . . . . . . . . .. . . .
>> . . . . . . . ..
>>
>> . . . . . . . . . .. . .
>> .. . . . . . . . . . . . .
>> . . . ..
Simon> . . . . . . . . .. . .. ... .
Simon> . . . .... . . . . . . . . ...
Simon> ....
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
. 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:
> . ..
>
> .. . . . . . . . . . . . ..
> . . . . . . . . . . . . ..
There is no intentional name re-ordering. I'll look into why that happens.
> . . . . . . . .. . ..
Ok, will check that too.
Thanks for the feedback!
Best regards,
Henrik
> ..
> .
>
>
>> ...... ......
>> .. ....... ........... . .
> . . .
>> .
>> .. .. . .. . ... .
>> .. . .
>> .. .. . .. .......
>> .. . . ... . .
>>
>>
>> . . . . . . . . . . .
>> . .. . . . . ..
>>
>> . .. . .. . .. . .. . .
>> .. .. . . . . .
>> . ..... . .. . ..
>>
>> .. ... . . . ... . . . . .. ..
>> . . . .. . . . .. .
>> . ...
>>
>> . . . . . . .. .. . . . . . . .
>> . . . .. . . ..... . . . . ..
>>
>> ..............
>>
>> . . . . . . . . . . . . . .
>> . . . . . . . .. . . . . .
>> . . . . . . . . . . . .. .
>> .. . .... . . . . . . . . . . . .
>> . . ..
>>
>> . .. .. . . . . ...
>> . .. . . .. . ..
>> .........
>>
>> .... . . . . . . . . . .. ..
>> . . . ..
>>
>> . . . . .. . . . . . . . . ..
>>
>> .
>>
>>
>>
>> . .. .
>> . . .. . . . .
>> . .
>> .. .. ..... .. .. .....
>> .... ..... .. ...........
>> .. .
>
>
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:
> . ..
>
> .. . . . . . . . . . . . ..
> . . . . . . . . . . . . ..
>
> . . . . . . . .. . ..
>
> ..
> .
>
>
> > ...... ......
> > .. ....... ........... . .
> . . .
> > .
> > .. .. . .. . ... .
> > .. . .
> > .. .. . .. .......
> > .. . . ... . .
> >
> >
> > . . . . . . . . . . .
> > . .. . . . . ..
> >
> > . .. . .. . .. . .. . .
> > .. .. . . . . .
> > . ..... . .. . ..
> >
> > .. ... . . . ... . . . . .. ..
> > . . . .. . . . .. .
> > . ...
> >
> > . . . . . . .. .. . . . . . . .
> > . . . .. . . ..... . . . . ..
> >
> > ..............
> >
> > . . . . . . . . . . . . . .
> > . . . . . . . .. . . . . .
> > . . . . . . . . . . . .. .
> > .. . .... . . . . . . . . . . . .
> > . . ..
> >
> > . .. .. . . . . ...
> > . .. . . .. . ..
> > .........
> >
> > .... . . . . . . . . . .. ..
> > . . . ..
> >
> > . . . . .. . . . . . . . . ..
> >
> > .
> >
> >
> >
> > . .. .
> > . . .. . . . .
> > . .
> > .. .. ..... .. .. .....
> > .... ..... .. ...........
> > .. .
>
>
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:
> . . . . . . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . .. . . . ..
>
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
>
> . .
> . . .
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:
> . . . . . . . ... . . . . .
> .. .
> . . . .. ..
>
> . ... . . . .. . . . . .
> .. .
> . . . . .. . . . . . . .
> . . .
> . .. ..........>
>
> . . . . . . . . .. .
> ..........>
>
> . . . . . .. . . . . . .
> . ..
> . . . . . .. . . . . .
> . . .
> ..
>
> . . . . . . . .. . .
> . .
> ..... <javascript:;>. . . . . .. .
> ............
> ...>
>
> . . . . . ..
>
> . . . . . . . . . .. . . .
> . .
> . . . .. . ... . .
> .................> . .
> . ... . . . ..
>
> . .
> . . .
>
--
Website: http://hallambaker.com/
news:CD5674C3CD99574EBA7432465FC13C1B22726A1D8C@DC-US1MBEX4.global.avaya.com
On Fri, 2012-07-20 at 06:07 -0700, IETF Administrative Director wrote:
> . . . . . . . . . . . . .
> .. ..............>
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
> . . ... . . . . . .. . .
> . . . . . . .. .
> ................ . . ..
<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
. . . . . . . . . . . . . .
. . . .
.
. . .. .. . ... .. . . ..
> > . . .. .. . ... .. . . . ..
> >> . . . . . . . . . . .
> >> . .
> >> .. ..............>
>
> . ..
news:500654AB.7060500@necom830.hpcl.titech.ac.jp
Joe Touch ..
>> .. . . . . . . . . . . .
>> . ... . . . . ...
>> . . . ..
>
> . . . . . . . . .
> . .. .
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?
> . . . . . . . .
> . . ..
Yes, even rate limiting translators may interfere each other,
which means rate limiting must be done at the IPv6 source
node.
> .. . . . . . . . ..... ..
In the ID, there are a lot of references to IPv6.
For example, the following statement of the ID:
Finally, the IPv6 ID field .
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 . modified as:
Finally, . IPv6 ID field .
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:
> . . . . . . . . . . . . . . .. . . . .
> . . . . . . . . ..
+1
I fail to see why Informational wouldn't be the better status.
Lars
news:20120711.053654.193724485.miyakawa@nttv6.jp
>> . . . . . . . . . .
>> . . . . ....
>
> . . . ..
+1
> . . . . . ....
>
> .. . . . . . . . . . .
> . . . ... . . . . . ...
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
. jul . kl. 23.42 skrev Paul Hoffman <paul.hoffman@vpnc.org>.
>> . . . ... .. . . . . . . . . . . . ..
>
> . . . . . . . . . . . ... .. ... . . . ..
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
>
> . . . . . . . . . . . . . ..
.
> . . . . . . . . . . . .
> .. . . . . . . . . . .
> . . . . . . . . . ..
>
> . . . . . . . . .. . . . .
> ......
>
> .
>
> . . . . . .
>
> . . . . . ... . ..
> .. .................. . .
> . . . . . .. . . . .
> . . .. . . . . . . . . . .
> . . . . . . . . . . .
> . . . . . . . . . ..
>
> . . . . . . . . . . . . . .
> . . .. . . . . . .
> . . . . . . . . . . ..
>
> . . . . . . . . . . ... .
.
> . . . ..
>
>
> ... . . ... .. . . . .....
> . . . . . . . ..
> . . . .. . .. . .
> . . ... . ..
news:9EF2836F-B9C6-47BF-AAE9-87DE15574E95@tzi.org
. . .. ., . 21.38. Marshall Eubanks ..
> . . . . . . . . ..
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 . 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:
> ... .. . .. . ... .. . .
> ......> ..
>
>> . . . . . .. . . ..
>>
>> . . . . . . . . . . .
>> ................>.
>>
>> . . .. . . . . . . . . . .
>> . .. . . . . . . . . . . .
>> . . . . . . . . . . . . .
>> .. . . . . . . . . ..
>> ...
> ..
>
> . . . .. . . . . . . .. .
> . . . . . . . . . . .
> . . . .. . . . . . .. . .
> . . . . . . . . . . .
> . . . . . . . . . . ..
> .. . . . . . ... . .
> . . . . . .. . . . . . .
> . . . . . . . . . .
> ... . . . . ..
>
> . . . ..
>
> .
>
news:500D03C9.9030305@gmx.de
On 2012-07-23 00:33, Stephen Farrell wrote:
>
> . ..
>
> ... . . . . . . . . . .
> . ... ... . . . ....
>
> . . ... . . . . . . .
> . . . . . . . . .
> . . . ... . .. ...
>
> . . . . . . . .
> . . . . . . . . . . .
> . . . . . . . ... . .
> . . . ... . . . . . ... . .
> . . . . . . . . . . . .
> ..
>
> . . . . . . . . . .
> . . . . . . . . .
> . . . . . . .. . . . .
> . . . . . . . . . ... . . .
> . . . . . . . . . ..
> ...
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:
> . .. . ..
>
> ..
>
> . ..
>
> . . . . . .. . ..
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:
> . . . . . .. . . ..
>
> . . . . . . . . . . .
> ................>.
>
> . . .. . . . . . . . . . .
> . .. . . . . . . . . . . .
> . . . . . . . . . . . . .
> .. . . . . . . . . ..
>...
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 . 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
>
>
> . . . . . . . . . . .
> . .. . . . . ..
>
> . .. . .. . .. . .. . .
> .. .. . . . . .
> . ..... . .. . ..
>
> .. ... . . . ... . . . . .. ..
> . . . .. . . . .. .
> . ...
>
> . . . . . . .. .. . . . . . . .
> . . . .. . . ..... . . . . ..
>
> ..............
>
> . . . . . . . . . . . . . .
> . . . . . . . .. . . . . .
> . . . . . . . . . . . .. .
> .. . .... . . . . . . . . . . . .
> . . ..
>
> . .. .. . . . . ...
> . .. . . .. . ..
> .........
>
> .... . . . . . . . . . .. ..
> . . . ..
>
> . . . . .. . . . . . . . . ..
>
> .
>
>
>
> . .. .
> . . .. . . . .
> . .
> .. .. ..... .. .. .....
> .... ..... .. ...........
> .. .
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.... .... .. . ..
. . . . . .
. . . . . . . .. . . . . ...
. . . . . . . . ... .... .
. . . . . . . . . . . .
. . . . . . . . . .. . .
. . .. ..
.. . . .. ... . . . . . . .... . . . . .. ... . . . . . . .. . ... . . . . ... ..
. . .. . . . . . .
.....
... . .. . . . . . .
. . . . . . .. . . . .
. ... ... . . . . . . . ....
..
.
..
. . .. .. . . ..> .........
... ... ..> .........
... . ..> .........
_______________________________________________
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 . . . ... . . . .. . . .
> .... . . . . .
> ......................>.
>
> . . . . . . . . . ..
>
> .. .............
> .. . .
> . .. .....
> . . . .. .....
> . . .. .
>
> .. . . . . . . . . . . .
> . . ..
>
> . .. .
>
> . ..
>
> . ..... . . . . . .. . . . . .
> . . . . . . . . . . . .
> . . . . . . . . . . .
> .. . . . . . . . . . . . .. . .
> ... . . . . . . . . .
> . . .. . .. . . . . . . .
> . . . . . . . . . . ..
>
> ... ..
>
> . . .... ... . . . . . .. .
> . . . .. . . . . . . . .
> . ..
>
> . . . . .. . . . . .
> .
> .. .. ...
> ............................
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
news:5005B58F.40608@qualcomm.com
. 7/3/12 7:51 AM, Eggert, Lars wrote:
> On . .. .. . .... . . ..
>
>> . . . . . . . . . . . . . . .. . . . .
>> . . . . . . . . ..
>>
> ..
>
> . . . . . . ... . . . ..
>
> .
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
. . .. .. . 12.07 PM. . . ..
>> . . . . . . . . . . . . . . . . . ... . . . .. . .. . . . . . . . .... . . ... . . . . . . ..
>
> . . . . .. . . . . . . . .
> . . . . . . . .. . . . .
> . ..
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 ... . . . . . . . . . . . .
> . . . . .. . . . .. . . . .
> . . ..
Even if that's the case having accurate documentation of the privacy implications can't hurt.
Alissa
>
> . . . . . . . . . . . ..
> . . . . ..
>
>
> ..
> .
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:
> . ..... ... .. . . ..
> > ... . . . . . . . . . . .
> > . . . . . . . . . . ..
>
> . . . . . . . . . . .... . .
> . . . . . .. . . .
> . . . . . .. . . . . . .
> . . . . . . . . . ..
> . ..
>
> .
>
>
>
news:20120711154158.60f6ecf0@hetzer
On Tue. . Jul . 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:
>>. . . . . . .. . . . . . ..
>
> . . . . . . . ..
>
(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:
> . . . . . ... . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . . . ... . ... . ..
>
> . . . ... .. . . . . . . . . . . . ..
For those of you whom are only now finding out about Bob's death, here's a bit of background:
. . 26. .. . ..06 .. Michael R. Gettes ..
> The tribute web site has been updated with information about the Memorial . . .
> be held this Sunday @ 11 AM Pacific Time. 2PM Eastern. 7PM London . 4AM Monday in Sydney.
>
> Please visit ..............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:
> . . .. . . ..
+1
> . . . . . . . . . ..
>
+1
> . .. . . . ... .. . . . . . . . .. . . . ... . .. ... . . . . . . . ... . .. . . . . . ... . . . . . . ..... . . . . . . . . . . . . . ..
>
-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
> .----. ......
> .. ....... ........... . . . . .
> .. .. . .. . ... .
> .. . .. . .
> .. [IETF] .. . .. ............> .. . . .. . . . .
>
>> . . . . . . . . . . .
>> . . . ..
>> . .. . . ..
>> ............> . . . .
>
> . . .
>
> .
>
>
--
"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: . . .. . . .. . . . .
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
. . web page.
news:50188662.6000809@levkowetz.com
Hi Ole,
On 2012-07-31 16:17 Ole Jacobsen said the following:
>
> . . . . . . . . . . .
> ..... ... . . . . . . .
> . . . .. . . . . . . . ..
> . . . . .. . . . . . . .
> . . . . . . . . ... . ..
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:
> > . . . . . . . . . . . . . . .. . . . .
> > . ..
>
> .. . . ... . . . . . . . .. . . .
> . .. ... . . . . . . . . .
> .. .. . . .. . . . . . . . . . .
> . . . . ...
>
> . . . .. . . . . . . ... . . .
> .. . . .. . . . . . . . . . . . .
> . . . ..
>
> ....
> .
>
news:4FF4684F.9030603@gmx.de
On 2012-07-04 16:52, Russ Housley wrote:
> ..
>
> . . . . ............. . . . . . . ..
>
> .
No, I was just trying to understand *why* the archive can't be at
..............>.
Best regards, Julian
news:29BF6AF1-3924-42F0-B8BD-1B1250CAECD6@hopcount.ca
Hi Russ,
On 2012-07-15, at 11:39, Russ Housley wrote:
> ..
>
> . . . .. ... . . . . .. . . . . . . . . ..
>
> . . . . . . . . . . .. . . . . . . . . . ..
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.
..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.... .... . . ..
>>
>> . ..
>>
>> ... . . . . . . . . . .
>> . ... ... . . . ....
>>
>> . . ... . . . . . . .
>> . . . . . . . . .
>> . . . ... . .. ...
>>
>> . . . . . . . .
>> . . . . . . . . . . .
>> . . . . . . . ... . .
>> . . . ... . . . . . ... . .
>> . . . . . . . . . . . .
>> ..
>>
>> . . . . . . . . . .
>> . . . . . . . . .
>> . . . . . . .. . . . .
>> . . . . . . . . . ... . . .
>> . . . . . . . . . ..
>> ...
>
> ..
>
>> ..
>>
>> . ... . . . . . . .
>> . . . . .... . .. . . .. .
>> . . . . . . . .
>> . . . . ... .............. .
>> . . . . . . . . .
>> . . . . .. . . . .
>> . . . ..
>
> . .. . . . . . . . . . . .
> . . . . . ..
"hides" isn't a goal:-)
> .. ..... ..
>
> ..
>
> .. . . . ... . . . . . .
> . . . . . . . . . . . .... .
> .. . . .. . . . . . . . . .
> . . ... . .... . . . . . . . .
> . . . . . . . ...
> .............. . . . . . . .
> . . . . . . . . ..
>
> . . . . . . . .. ....
That looks better. I've updated the RFC editor note to
use your text.
Thanks,
S.
>
> . .. .
>
>
>
>
news:F47AEC1A-E11F-45C2-9371-61B4A52FBA9D@gmail.com
Richard,
. . .. .. . 9:40 AM, Richard L. Barnes wrote:
>
> On Jul 20, 2012, at ... .. . . ..
>
>> . ..... ... .. . .. . ..
>>> . . . .. . . . . . .. . . . . .. . . . . . . . . . .. . . ... . . . . . . . . . . . . ..
>>
>>
>> . . . . . . . . ... ..
>>
>> ..
>
>
> .. . .. . . . . . . . . ... ..
>
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,
. 10/..2012 18:50, Simon Perreault wrote:
> On 07/... ... .. . . ..
>> . . . . . ... . . .... . .
>> . .
>> . . . . . . . . . . . . ..
>
> ... . .. . . . . . . . .. ... .
> . . .. . . . . . . . .. . ...
> . . . . . . . . . . .
> .. .. . . . . . . . . .. .
> . ... . . . . . . . . .
> . . . .. . . . . . . .
> . . . . . ... . . . .. . .
> ... . . . . . . .. . .
> . . . . . . . . . . . .
> .. . . . . . . . . . ..
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.)
> .. ... . . . . . . . . . . . . .
> .. . . . . . . . . . .. . .
> . . . ... . . . . .. . . . .
> . . . . .. . . . . . . . .
> . . . . . . . ..
>
> .... . . . . . . . . .
> . . . . ... ..
>
> .. . . . . . . . . .
> . . . . . . . . ... ..
> . . . .. . . . . . . . . .
> . . . . . .. . . . .
> . ... . . .. . . .. . . .
> . . . .. . . . . .
> .. . . . . . . ..
>
> . . . . ....
>
>
> ... ..... ...
> ...... ... ...... ... .....
> . . . . ... . . . ... . . .
> . . .>>>>>>>>>>>>. . .>>>>>>>>>>>>>>. . .
> . . . . . . . . .
> . . .............. . ................ . .
> . . .. ... . .. ... . . .
> . . . . ... . . . ... . . .
> ..... ..... .....
>
> . .. . ...
>
> ..
> .
news:2A096686-53B2-42C0-8A7B-CEDD691AB2AD@gmx.net
Hi Yoav.
>
> .
>
> . .. . ... . . . . . . . . .. . ..
>
Barely anyone has done that.
> . . . . . . . . .. . . . . . .. .. . .. . . .. . . . ..
Eran claims that enterprise identity management equipment manufacturer dominate the discussion.
>
> . . . . . . . . . . . .. . . . . . ..
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.
> . . . . . . .. . .. . . . .. . . . ..
The OAuth group is more a consumer of security expertise rather than the source.
Ciao
Hannes
>
> .
news:20120711164111.1b9e86d5@hetzer
. Tue, 10 . 2012 12:32:08 -0400
Alissa Cooper <acooper@cdt.org> wrote:
> On Jul .. .. . ... .. . . ..
> >> . . . . . . . . . . . . . . . . . ... . . . .. . .. . . . . . . . .... . . ... . . . . . . ..
> >
> > . . . . .. . . . . . . . .
> > . . . . . . . .. . . . .
> > . ..
>
> .. ... . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . ..
>
> . . . . . . . . . . . .. . . .. . ... ... ... . . . . . . . . . . . . . . ..
Off-list discussion with Alissa resulted in this suggestion:
"Proxies using this extension . preserve the information of a direct
connection. This has an end-user privacy . regardless of whether
. end-user . deployer knows or expects . this is . .."
..
.
news:20120710132756.4dac582d@hetzer
On Mon, 9 Jul 2012 14:27:49 -0400
Alissa Cooper <acooper@cdt.org> wrote:
> .. . . . ......................... . . . ..
>
> . . . . . . . . . . . . . . . . . . .. . . . . .. . ... . .... .. . . . ..
>
> .. . .
> . . . . . . . . . . . .
> . . . ...
>
> .. . . .. . . . . . . . .
> . . . . . . . ...
Well, I think it gives a good hint to use dynamically assigned tokens.
> . . . . . . . . . . . .... . ... . . . . . . ..
I guess so.
> . . . . . . .. . . . . . . .
> . . . . . . . . .
> . . . . . . . . . . . .
> . . ... . . . . . . . .
> . ... ..
>
> ... . . . . . . . . . . . . . . . . ..
>
> .. . . . ... . . . . . . . . ..
>
> .. . . . . . . . . .
> . .. . . . ... . .. . . ..
> . . . . . . . . . . . . ...
>
> . . . . . . . . . . . . . ... . ..
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
. Yaron.
At 05:52 AM 7/29/2012, Yaron Sheffer wrote:
>. . . .
>.............................
>. . . . . ... . . . .
>. . . .. .. . .. . .
>. . . . . . . . .. .
>. . . . . . . .. . .
>. . .. . . . . .
>.. . . . .. . . .. . . . ..
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
>
> ..
>
> ... . . . ....
>
> . . . . . . . . . . .. . . .
> . . .. . . . .... ... . . . .
> . . . . . . . . . . . .. ... . ..
> . . . . . . ... . . . . . .
> . . . . . . . . .. .
> . . . . ... . . . . . . . . . .
> . . . . . .. . . . . . . . .
> . . . . . . . . . .
> . . ... ..
>
> . . . . .. . ... . . . . . . .
> . . . . . . . . . . . .
> . . ... .. . . . . . . . .
> . . . ..
[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.
>
> . . . .. . . ..
>
> > . . . . . ... . .. . .. . .
> . . . . . . . .. . . . . .
> . ..
>
> . . .. . . . . . . .....
[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:
> . . . . . . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . .. . . . ..
>
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
20 march is palm sunday on the western calender.
If one's a conflict presumably the other is too...
> . .
> . . .
>
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 :
> . . . . . . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . .. . . . ..
>
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
>
> . .
> . . .
>
>
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:
> . . . ... . .. .. ..... . . . . . . . . . . . . . . . . . . . . ..
news:alpine.BSF.2.00.1207231441180.17130@fledge.watson.org
On Fri, 20 Jul 2012, Behcet Sarikaya wrote:
> . ... . . . . . . ..
> . . ... .. . . . . . . . . .
> . . . . . . ..
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
. 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:
> . . . . . . . . . . . . . . .
> . . . . . . . . . . . .
> . . ..
>
> . . . . . .. .. . . .
> . . . . . . . . . . . .
> . . .. . . . . . .. . . . . . . . .
> . . . .. . . . . . . . . . .
> . . . . . ..
>
> . . . . . . . . . . .. . .. . .
> . . .. . . . . . . .. . . . .
> . . . . . . .. . . . . . . . . ..
> . . . . . . . . . . ..
>
> . . . . . . . . . . . . . . .
> . . . . ..
>
> . . . . . . . . . . . . .
> .. ..............>
>
> . . . . . . . . . . . . . .
> .. . . . ..... . . . ..
>
> . .
> . . .
>
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:
>. . . . . .. . . ..
>
>. . . . . . . . . . .
>................>.
>
>. . .. . . . . . . . . . . .
>.. . . . . . . . . . . . . .
>. . . . . . . . . . . .. . . .
>. . . . . ..
The interesting question . 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:
> .. . . . . . . . .. . . .
> . . . . ..
As draft editor, I would ask for a justification. I can't add a
requirement without a justification.
> . . . . . .
> . . .. . . . . . ..
I don't know, I'm just an editor. What specific text in the draft do you
think needs to be changed?
> . . . .
> . . . . . . . . . . . . . . ...
> . . . . . . . . . . . . . ..
No. It refers to the external address pool used by the CGN.
> . . . . . . .. . . . . . .
> . . . . . . . . . . . . .
> . ..
Sorry, I don't understand . question.
> .. . . . . . . . .
> .. . . . .. . . . . . . . . .
> . . .. . . . . . . . .
> . . ... . . .. . . . . . ..
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 . . . . . . . . . . . .
> . . . . ..
How could any NAT work without such a database? I probably misunderstand
what you're suggesting...
> . . . .. . . .
> . . . . . . . . . . .
> . . . . . .. . . . . . . .
> . . . . . . . . . . . ..
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.
> . . . . . . .. . . .
> . . . . . .. . . . . . .
> ... .. . . . . . . . .
> . . . . . . .. . . .. . .
> . . . . . ..
I'm sorry, I don't understand this proposal. Maybe an example would help?
.
..
. . .. .. . . ..> .........
... ... ..> .........
... . ..> .........
news:5DC517E1-12ED-4DCD-B1F1-8B67157727AA@nordu.net
20 jul 2012 kl. 16:09 skrev "Richard L. Barnes" <rbarnes@bbn.com>:
> ..
>
> . . . . . . . . . . . . .. . . . . . . ... . ..... . . .. . . . ...
>
I could think of some other things it could say too...
> ...
>
>
>
> . . .. .. . ... .. . . ..
>
>>
>> . . .. .. . ... .. . . . ..
>>
>>> . . . . . . . . . . . . . . .
>>> . . . . . . . . . . . .
>>> . . ..
>>>
>>> . . . . . .. .. . . .
>>> . . . . . . . . . . . .
>>> . . .. . . . . . .. . . . . . . . .
>>> . . . .. . . . . . . . . . .
>>> . . . . . ..
>>>
>>> . . . . . . . . . . .. . .. . .
>>> . . .. . . . . . . .. . . . .
>>> . . . . . . .. . . . . . . . . ..
>>> . . . . . . . . . . ..
>>>
>>> . . . . . . . . . . . . . . .
>>> . . . . ..
>>>
>>> . . . . . . . . . . . . .
>>> .. ..............>
>>>
>>> . . . . . . . . . . . . . .
>>> .. . . . ..... . . . ..
>>>
>>> . .
>>> . . .
>>>
>>
>>
>> ....
>>
>> . . . . . .. . .. . . . . . . .. . . . . . .. . . . . .. . . ... . . . . ....
>>
>> .
>>
>> ..
>> . . . .. . . . . . . .. .. . ..
>> .. .. .. .
>>
>>
>>
>
news:201207231704.q6NH4dtB025884@mtv-core-3.cisco.com
At 07:28 AM 7/23/2012, DRAGE, Keith (Keith) wrote:
>... . . . . . . . . . .
>. . . . ..
>
>. . . . . . . .. . ... . .
>. . . .. . . . . . . . . . .
>. . . . . . . . . . . .
>. . . . . . . . . . . .
>... . . . . . . . . . .
>. . . . ..
>
>. . . . . . . . . . . .. .
>. . . . . . .. . . . . .
>. .. . . . . . .. . . . . . ..
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
>. . . . . . . .. . . .
>. . . . . . . .. . . . .
>. . . . . . . . . . . . .
>. . ..
>
>. . . . .. . . . . . . . . .
>. . . . . . . . . . . .. .
>. . . . . . . . . . .
>. . .. . . . . . . . . . . .
>. . . . . . ..
>
>.
>
>.... . . . . . . . . . .
>. .. . . . . . . .
>. . . . . . . . . . . .
>. ..
>
> > ...... ......
> > .. ....... ........... .
> > . . . . .
> > .. . . . ...
> > .. . . .
> > .. ...... ...... ...... .....
> > .. . . . . .
> >
> > . . . . . . . . . . . . .
> > .
> > . . . ..
> >
> > . . . . . . . . . . . .. . . .
> > ..
> >
> > . . . . . . . . . . . . . . .
> > . .
> > . . . . . . . .. . . .
> > .....
> > . . . ..
> >
> > . .
> > . . .
news:80322321-0A40-4F3C-A180-B4AA6AFF4277@cisco.com
On Jul 20, 2012, at 11:37 AM, Behcet Sarikaya wrote:
> . ... . . . . . . ..
> . . ... .. . . . . . . . . .
> . . . . . . ..
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. . larger the interval you want to put off limits, the more interactions it has.
If you are personally a Muslim, this . . question . you; if not, then its a question . 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 . 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..../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-. 14.20. David Harrington . écrit :
> . . . . . . . . . . .
> .. . . . . . . . . .
> . . . . . . . . . . .
> . .. . . . . . . . . .
> . . . .. ..
> . . . . . ... .. . . .....
> . . . . ..
> . . . . . . . . . .
> ... . ..
> . . . . . . . . . .. .
> . . . . . ..
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 .. up to . implementer and operator.
> . .. . . . . . . . .. . . ..
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.
. NAT function . . wifi hotspot . . 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
. IPv4 sunset, but how CGN behaves is up . 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:
>> .. . . .........
>>
>> . . . . . . . . . . ..
>
> ... . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. .. . . . . . . . . . ... . . . ..
>
> .
news:9261E011-DA3D-4BDA-A7AF-720C4539BAED@vpnc.org
On Jul 20, 2012, at 9:06 AM, . Administrative Director wrote:
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
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:
> ... . . . . . . . . . . .
> . . . . . . . . . . ..
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
. . . . . . . . . . . . . . . . . ..
. . . . . . . . . . . .. . . . ..
. . . . . . . . . . . . . . . . . . . . . . . . .. . . . ..... . . . ..
. .
. . .
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 ..... .... . . . ..
>> . . . . . . . . . . . . . .
>> . . . ..
>>
>> . . . . . . . . . . . .. . . . ..
>>
>> . . . . . . . . . . . . . . . . .
>> . . . . . . . .. . . . .....
>> . . . ..
>>
>> . .
>> . . .
>
> . . . . .. . ... . . . . . . . ..
> . . . . . .. . . . . . . ..
> . . . . .. . . . . . . ..
>
> . . . . . . . . . . . .. . . .
> . . . . . . . . . . ... ..
13 - 18 March 2016 are the dates for the IEEE-802 Plenary.
Ray
> . . . .
> ... ..
>
> .
>
>
>
> ..
> ..............................................................................
> . . .. .......
> .........
> .. ......
> ..............................................................................
>
> . . . . .............
news:E0BFBA85-85C2-46BA-8406-99990C204295@vigilsec.com
Joe.
>> . . . . . .. . . .. . . . . . . .. . . . . . . .. . . . . . . . ..
>
> ... .. . . . . .. . . ...
>
> . . . . . . . . ... . . . . . . . . . . . . . . . . .. . . . . . . . ... . . . . . . . . . . . ... . ..
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> . . . . . . . . . . .
David> .. . . . . . . . . .
David> . . . . . . . . . . .
David> . .. . . . . . . . . .
David> . . . .. ..
This doesn't make any sense . 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 . . not . case.
The customer gets to choose a CPE vendor and the operator gets to choose
. CGN vendor.
. deployment environment here is the Internet.
In cases like this . . past we . chosen . 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 . one ISP . choose DNS.
We want customers name resolution to continue to work (with the same CPE
they already have) as they move from one ISP . 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 . 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, . 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
>>> . . . . . . . . . . . . .
>>> .. ..............>
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
> . .. . .. . . ... .. . .
> ......> ..
>> . ..
>>
>> . . . . . ... . . . . . . . .
>> . . . .. .. . . . . .
>> . . . . . . . . . . . .
>> . ..
>>
>> . .. . ..
>>
>> ..
>>
>> . ..
>>
>> . . . . . .. . ..
>
> . ... . . . . .. . . . . . .
> . . . .. . . . . . . . .
> ..
>
news:CAPv4CP-zy1uUqXfXqNH9R1C-NTe+11pxgJ5ceZaR1=oU2E1T=A@mail.gmail.com
>
> > . . .. .. . ... .. . . . ..
> >> . . . . . . . . . . . .
> .
> >> .. ..............>
>
Fine ..
news:07F7D7DED63154409F13298786A2ADC90451F5A8@EXRAD5.ad.rad.co.il
> . . . ..... . . . . . . . . . ..
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
. . . . . . . . . . . . . . . . . ..
. . . . . . . . . . . .. . . . ..
. . . . . . . . . . . . . . . . . . . . . . . . .. . . . ..... . . . ..
. .
. . .
news:20120710132833.0d6d6b02@hetzer
On Mon, 09 Jul 2012 22:48:59 +0100
Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> . . . . . . . . . ...
> . . ... . . . . .
> . . . ..
>
> . .. ... . . . . . . .
> . ... . . . . .
> . ..
"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.
> . . . . . . . . . .
> . . . . . . .. . . . . .
> . ... . . . . . ..
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?
> . . . .. ... . . .
> . . . .. . . . . . .
> . ..
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.
> . . . . . . . . .. .
> ... . . . . . . . . .
> .. . . . .. ... . ...
> . ... . . . . ..
>
> . . . . . . . . .
> . ... . . . ..
Yes.
Cheers.
Andreas
news:D7593A6A-41F7-4004-9249-FBBA5030D1C4@cisco.com
. Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote:
> On ..... ... . . . . ..
>> . . . . . . . . . . . . . .
>> . . . ..
>>
>> . . . . . . . . . . . .. . . . ..
>>
>> . . . . . . . . . . . . . . . . .
>> . . . . . . . .. . . . .....
>> . . . ..
>
> . . . . . . . . ..
>
> . ... . . . . . . ....
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:
> . . . . . . . . . . . . . ..
>
> . ... . . . . . . . .. . ... . . . . . .. . . . .. . . . . . . . . ..
>
> .
news:alpine.BSF.2.00.1207221642080.31418@joyce.lan
> . . . . . . . . . . . .. . . . . . . . . . ..
>
> . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . .
> . . . . . . . . ... . . . . .
If the opposing party didn't pay you for your time in the depo, you did
them an unnecessary favor.
..
. .. ...... . .. . .
.. . . ... . .. ..
news:50097FAE.9060805@dcrocker.net
On 7/20/2012 7:25 AM, Richard L. Barnes wrote:
> . . . .. . . . . . .. . . . . .. . . . . . . . . . .. . . ... . . . . . . . . . . . . ..
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
>
> .. . . . .. . . .. ..
>
> . . . .. . . . . . .. . . . .
> .. . . . . . . . . . ..
> . . ... . . . . . . . . .
> . . . ..
>
>
>
>
> . . .. .. . ... .. .. . ..
>
> > . . . . . . . . . . . . . .
> .
> > . . .
> >
> > .
> >
> > . . .. .. . ... .. . . ..
> >
> >>> . . .. .. . ... .. . . . ..
> >>>> . . . . . . . . . . . .
> .
> >>>> .. ..............>
> >>
> >> . ..
> >
> >
> >
news:DA020552-9B8C-45FF-8D89-41894D2C4410@verisign.com
On Jul 30. 2012. at 1.18 PM, Richard L. Barnes wrote:
>>>
>>> ..
>>>
>>> ....
>>> ... . . . . . . . . . . .
>>> . . .. . . . . . .. . . .
>>> . . . . . . . . . ... .
>>> . . . . ..
>>
>> . . . . . . . . .. . .. . .
>> . . . . . ... . . . .. .
>> . . . . . . . . . ... . . .
>> . . . .. . . . .. ... . . .
>> . . . . . . . . . . . . ...
>> . . . . . . . . . .. ... . ..
>> . . . . . . . . . . . .
>> . . . .. . . ..
>
> . . . . ... . .. ... . . . . . . . . .. . . . . .. . . . . . . ..... ... . . . ... ..
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.
> . . . . .... . . . . .. . ... . . . . . .. . . . . . . . . . . . . . .. ... . . . . . ... . . . . ..
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:
>. . .. .. . ... .. . . ..
>
> > . ..... ... . . . . ..
> >> . . . . . . . . . . .
> . . .
> >> . . . ..
> >>
> >> . . . . . . . . . . . .. .
> . . ..
> >>
> >> . . . . . . . . . . . . .
> . . . .
> >> . . . . . . . .. .
> . . .....
> >> . . . ..
> >
> > . . . . . . . . ..
> >
> > . ... . . . . . . ....
>
>. . . . . . . . .. . . .
>. . . . . ..
>
>.. . . . . .. . . . . . . . .
>.. . . .. .. . . . .. . .
>.. . . . . . . . . .. .
>. . . . ..
>
>. .. . . . . . . . ..
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: . 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.... .... . . ... ..
> . . .. .. . ... .. . . ..
>
>> . . . . .. ... . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . ..
>
>
> . . . . . . . . . ....
.. . . ..................
. . . . . . . .. . . . . . . . .
. . . . .. . . . . . . .
. . .. . . . . . . . .
.. . . . . . . .. . . .. .
... . . . . . . . . . . .. .
. . . . . . ..
. . . . . . . . . . . .. .
. . . . . . . . . . ..
.
********************************************************************
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
>
> ... . . . . . . ..
thanks for your comment
>
> .. . . . . . .
> . . . . . . . . .
> .. . . .. ..
>
I agree that I will need to add to the technical draft for now.
> . . . . . . . ...
> . . . . . . . ... .
> . . . . . ... ..
>
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
===
>
> . ..... ... .. . . ..
>> . ..
>>
>> . . .. .. . .. . . . . . . . . .. . .
>> ... . . . . . . . . . .
>> . . .... . . . . . . . . . .
>> . . . . .. . .. .. . .. . .
>> . . . . .. . . . .
>> . . . ..
>>
>> ......................................................................................................
>> .>.> . . . . .. .
>>
>> . . . .. . . . .. . . .
>> . .. . . .. . . . . .
>> . . . . . ..
>> ......................................................................................................
>> .>. .> . . . . . . . .
>>
>> . . . . . . . . . . .
>> ... .. . . . . . ...
>> . .. . . . ... . . . .
>> . . . .. . . ... . . . .
>> . . . . . .. . . . .
>> . . . . . .. . . . . . . .
>> . . . ... .. . . . .. .
>> . .. . . . . . . . . . .
>> . . . ...... . . . . . . .
>> . . . . ... . . . . . .
>> .. . . . . . . . . . .
>> . . .. . . . . . ...
>> . . . .. . . . . . . .
>> ... . . .. . .. . ... .
>> . . . . . ..
>> ..................................................................................
>> .>. .>
>>
>> . . . . .. . . . . .
>> . .. .. . ..
>> ...................................................................................
>> .> . .> . . ... . . . . .. .
>>
>> . . . . .
>> ....... . . .. . . . . .
>> . . ................ . . . . .
>> . . . . . . ..
>> ...................................................................................
>>
>> . . . . . . . . . . . . ..
>> . . . . . . . ... . . . . . . .
>> . . . . . ..
>>
>> .
>>
>> . .
>> . . .. .
>> ..................................
>>
>>> . . . . . . . . . . . .
>>> . . . . . . . ..
>>
>>> .
>>
>>
>>> . .. . .. . . ... .. . .
>>> ......> ..
>>>> . ..
>>>>
>>>> . . . . . ... . . . . . . . .
>>>> . . . .. .. . . . . .
>>>> . . . . . . . . . . . .
>>>> . ..
>>>>
>>>> . .. . ..
>>>>
>>>> ..
>>>>
>>>> . ..
>>>>
>>>> . . . . . .. . ..
>>>
>>> . ... . . . . .. . . . . . .
>>> . . . .. . . . . . . . .
>>> ..
>>>
>>
>>
>
news:1343593068.9245.0.camel@gwz-laptop
On Sun, 2012-07-29 at 12:19 -0700, Hannes Tschofenig wrote:
> . . . . . . ..
>
> . . .. .. . ... .. . ..
>
> > .... . . . . . . . . . .. . . .
> > . . . .. .. . . . .. . . . . . .
> > . . . . . ... .. . . . . . . .
> > . .. . ...
>
> . . . . . .. . .. .. . . . . . .. . . . . . . ..
>
> . . . . . . .?
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:
> ... . . . . . . . ..
> . . . . . . . . . .
> . . . . ..
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:
>> . . . . .. . . . . . . .
>> . . . .. . . . . . . . .
>> . . . . . ..
> . . .. . . . . .. . . . .
> . . . . . . . ..
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.
> ... . .. . ... . . . . . . .
> . . . .. . . . . .. . .. .. . .
> . . ..
Indeed. A lot of things I might not be willing to support in the general
case are fine in the guise of experiments.
> ....
> .
>
news:CAJNg7VKqbdXeFXCe6iBRPe=X89q4NuSVcgvmc+C=t0826HRwiA@mail.gmail.com
On Sun, Jul 22, 2012 at 10:54 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> . . .. . . . . . ..
>
> . . . . . . . . . . .... .
> . . . . . . ..
>
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
> . . . . . . . . . . . . .
> . . . ..
>
> . .. . .. . . ... .. . .. . ......> ..
>> .. . . . .. . . .. ..
>>
>> . . . .. . . . . . .. . . . . .. . . . . . . . . . .. . . ... . . . . . . . . . . . . ..
>>
>>
>>
>>
>> . . .. .. . ... .. .. . ..
>>
>>> . . . . . . . . . . . . . . .
>>> . . .
>>>
>>> .
>>>
>>> . . .. .. . ... .. . . ..
>>>
>>>>> . . .. .. . ... .. . . . ..
>>>>>> . . . . . . . . . . . . .
>>>>>> .. ..............>
>>>>
>>>> . ..
>>>
>>>
>>>
>>
>
>
>
> ..
> .. ........
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:
> . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . .
> . . .
>
> .
>
> . . .. .. . ... .. . . . ..
>
>> . . ... . . . . . .. . .
>> . . . . . . .. .
>> ................ . . ..
>>
>> .
>> . .
>>
>> . ..... .... ....... ..
>>> . . ... . . . . ... ... ..
>>>
>>>
>>> . . ... ... . . . . .
>>> .... . . .
>>> . . .
>>> . .
>>> . .
>>> . .
>>> . . ...................
>>> . . .
>>> . . .....
>>>
>>> ..
>>> . . . ... . ... .. . .
>>> . ... . . . . ... .
>>> . . . . .. . .. ... . . .
>>> . . . . . . . . . . . .
>>> . . . . . . .. . . . .
>>> . . . . .. . . . ..
>>> . . . . . . . . . .
>>> . . . . . ... . . . . .
>>> . . . . . . . . .
>>> . . . . . . . . . . .
>>> . . . . . ... . . . ... .
>>> ..
>>>
>>> . .. . . . . . . . . . ...
>>> . . . . . . . . . .
>>> . . . . . . . . . .
>>> . . . ... . . ... . .. . .
>>> . . . . . . . . .. . .
>>> . . . . . . . . . . . . . . . . .
>>> . . . .. . . . . ...
>>> . . . ... . . .
>>> . . . . ..
>>>
>>>
>>> . . . . . . . . ..
>>> ...........................
>>>
>>> ... . . . . . ..
>>> .............................
>>>
>>>
>>> ... . . . . . . ..
>>> ..............
>>>
>>> .
>>> ..... . .
>>> .........
>>> ...................
>>> ... .. .............
>>> . .................
>>>
>
--
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
> . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . .
> . . .
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 . . . . .. .. . . . . . . .
> . . . . . . . . . . . . . . .
> . . . . . . . .. . . .
> . . . . . . . .. . . .
> . . . . . . . . . . . . ..
>
>
> .
>
>
> ...... ......
> .. ......... ...
> .......... . . . . . .
> .. .. . .. . ... .
> .. . . .
> .. ...... ...... ...... ......
> .....
> .. . . . . .
>
> . . . . . . . . . . . . .
> . . . . ..
>
> . . . . . . . . . . . .. . . .
> ..
>
> . . . . . . . . . . . . . . .
> . . . . . . . . . .. .
> . . ..... . . . ..
>
> . .
> . . .
>
news:500C56F3.6090909@gmail.com
On 7/22/12 11:25 AM. John Levine wrote:
> . . .. . . . . . . . . . .
> . . . . ..
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:
> ..
>
> ... . . . . . ... . . .. . . . . . . . . . . . ... . . . . ....
>
> . ... .. ... . . .. . . . . ... . . ... . . . . . . . . ......
>
> . . . .. . . ... ... . . . . . . . .. .. .. . ..
>
> . . . . .. ...
>
> ..............
>
>
> ..
>
news:CAJNg7V+GrzOcLKkHcVkxy07pjgvBjFuO8HOsyTSNQYjs-uoJ1A@mail.gmail.com
On Fri, Jul 20, 2012 at 9:23 AM, Jiankang Yao <yaojk@cnnic.cn> wrote:
>
>
> . . . . . . . .. . . . . . . .
> ..
>
> . . . . . . . . . ..
>
>
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
>
> . .
>
> ..... . . ..... .. .. . ..
> ......>
> .. .. . .. ........>
> .. ......>. ......>. ......>. ......>
> .. .. . .. . ... .
> .. . . . . . .
>
>
>
> . . . . . . . . . . . . . .
> .
> . . . . . . . . . .
> . .
> . . ..
>
> . . . . . .. .. . .
> .
> . . . . . . . . . . .
> .
> . . .. . . . . . .. . . . . .
> . . .
> . . . .. . . . . . . .
> . . .
> . . . . . ..
>
> . . . . . . . . . . .. . ..
> . .
> . . .. . . . . . . .. . .
> . .
> . . . . . . .. . . . . . .
> . . ..
> . . . . . . . . . . ..
>
> . . . . . . . . . . . . .
> . .
> . . . . ..
>
> . . . . . . . . . . . . .
> .. ..............>
>
> . . . . . . . . . . . . .
> .
> .. . . . ..... . . . ..
>
> . .
> . . .
>
news:20120710060912.GA19405@1wt.eu
On Mon, Jul 09, 2012 at 10:48:59PM +0100, Stephen Farrell wrote:
>
> . . . . . . . . . ...
> . . ... . . . . .
> . . . ..
>
> . .. ... . . . . . . .
> . ... . . . . .
> . ..
>
> . . . . . . . . . .
> . . . . . . .. . . . . .
> . ... . . . . . ..
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:
>
> . . .. .. . ... .. . . . ..
>
>> . . . . . . . . . . . . . . .
>> . . . . . . . . . . . .
>> . . ..
>>
>> . . . . . .. .. . . .
>> . . . . . . . . . . . .
>> . . .. . . . . . .. . . . . . . . .
>> . . . .. . . . . . . . . . .
>> . . . . . ..
>>
>> . . . . . . . . . . .. . .. . .
>> . . .. . . . . . . .. . . . .
>> . . . . . . .. . . . . . . . . ..
>> . . . . . . . . . . ..
>>
>> . . . . . . . . . . . . . . .
>> . . . . ..
>>
>> . . . . . . . . . . . . .
>> .. ..............>
>>
>> . . . . . . . . . . . . . .
>> .. . . . ..... . . . ..
>>
>> . .
>> . . .
>>
>
>
> ....
>
> . . . . . .. . .. . . . . . . .. . . . . . .. . . . . .. . . ... . . . . ....
>
> .
>
> ..
> . . . .. . . . . . . .. .. . ..
> .. .. .. .
>
>
>
news:8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu
On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:
> . . ..
>
>>> .. . . . . . . . . . . .
>>> . ... . . . . ...
>>> . . . ..
>>
>> . . . . . . . . .
>> . .. .
>
> . . . . . . .. . .
> . ..
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.
>> . . . . . . . .
>> . . ..
>
> .. . . . . . . . ..
> . . . . . . . . . . .
> ..
>
>> .. . . . . . . . ..... ..
>
> . . .. . . . . . . . ..
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.
> . .. . . . . . ..
>
> .. . . . . .
> . .. . . . . ... . . .
> .. . . . . . . . . . . . .
> ..... ..
>
> . . . ..
>
> .. . . . . .
> . .. . . . . . . . .
> ... . . .
> ..
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
. .. ..... . 23.37 +0300. Yoav Nir ..
...
> >> . . . . . .. . .. .. . . . . . .. . . . . . . ..
> >>
> >> . . . . . . ..
> >
> > . . . . . . . ... . . . ..
>
> .
>
> . .. . ... . . . . . . . . .. . ..
>
> . . . . . . . . ..
The particulars are immaterial. The question was as general (& I
suppose, philosophical) as Hannes'.
> . . . . . .. .. . .. . . .. . . . ..
>
> . . . . . . . . . . . .. . . . . . .. . . . . . . .. . .. . . . .. . . . ..
>
> .
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:
>
>
> .. . . . . . . . . . . . . . . . .
> . . . . . . . . . . ..
>
> . .. . .. . ..
>
> . . . . . . . . ...
> ..
>
> . . . . . . ... . . .
> . . . . . . ..
>
> .
>
>
>> ...... ......
>> .. ......... .......
>> ...... . . . . .
>> .. .. . .. . ... .
>> .. . .
>> .. .
>> .. . . . . . .
>>
>> . . . . . . . . . . . . . ..
> .
>> . . . . . . . . . . . .
>> .. . . . . . . . . . .
>> . . . . . . . . . ..
>>
>> . . . . . . . . .. . . . .
>> ......
>>
>> .
>>
>> . . . . . .
>>
>> . . . . . ... . ..
>> .. .................. . .
>> . . . . . .. . . . .
>> . . .. . . . . . . . . . .
>> . . . . . . . . . . .
>> . . . . . . . . . ..
>>
>> . . . . . . . . . . . . . .
>> . . .. . . . . . .
>> . . . . . . . . . . ..
>>
>> . . . . . . . . . . ... .
> .
>> . . . ..
>>
>>
>> ... . . ... .. . . . .....
>> . . . . . . . ..
>> . . . .. . .. . .
>> . . ... . ..
news:1876CD0A-DD0A-4253-B559-0A4F041DA3DE@checkpoint.com
. Jul 29, 2012, at 1:17 PM, Glen Zorn wrote:
> On .. ..... . ... ... . . ..
>>
>> . . . . . . ..
>>
>> . . .. .. . ... .. . ..
>>
>> > .... . . . . . . . . . .. . . .
>> > . . . .. .. . . . .. . . . . . .
>> > . . . . . ... .. . . . . . . .
>> > . .. . ...
>>
>> . . . . . .. . .. .. . . . . . .. . . . . . . ..
>>
>> . . . . . . ..
>
> . . . . . . . ... . . . ..
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... ]
> >> ... . . . . . . . . . . .
> >> . . . . . . . . . . ..
> >
> >. . . . . . . . . . .... . .
> >. . . . . .. . . .
> >. . . . . .. . . . . . .
> >. . . . . . . . . ..
> >. ..
>
> . . .. . . . . . . . . . .
> . . . . ..
>
> . . . .. .. . . . . . . .
> . . . . . . . . . .. .
> . . . . . . . . ..
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
>
> . . . . . . . . . . ..
> . . . . . . .... . . . .
> . . . . . . . ..
>
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.
>. . . . . . . . . .
>. .... . ... . . . . . .
>.. . . . . . . .. . . . .
>. . . . . . . . . . .
>. . . . . . . . . . .
>. . . . ... . . . . .
>. . . . ... ..
Yes.
>... . . . . . . . . . .
>. . . . . . ..
>
>.. . . . ... . . . . . . . . ..
>
>.. . . . . . . . . .
> . .. . . . ... . .. . . ..
> . . . . . . . . . . . . ...
I suggest removing that statement. The wording is not entirely
clear. I read it as diluting end-user privacy impact.
. Section 6.3:
'To distinguish the obfuscated identifier from other identifiers,
. MUST . . leading underscore "_".'
I suggest removing the requirement and using "can". The implementer
can decide . . . in . 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.
> .. . . . . . . . .. . . . . . . . ..
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 ?
> . . . . . . . . .. . . . . . ..
I think . it's operators' choice :-)
<snip>
> . . . . . . . . . ..
I also think this kind of information is usuful, but
this could be discussed in other draft isn't it ?
> .. . . . . . . . . .. . . . .. . . . . . . . . . . . .. . . . . . . . . . . ... . . .. . . . . . ..
I see... Especially, Simon, how do you think ?
>
> . . . . . . . . . . . . . . . . . ..
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 . play starting . . 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
. . July . 06.55. Yoav Nir <ynir@checkpoint.com> ..
> . . . . .. . . . . .. . . . . . . . . . . . ..
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 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
. ..
. ..... .... . . ..
>
> . . ..
>
> . ..... ... .. .. .. .. ..
>> . . . . .. ... . . .. . ... . .
>> . . . . .. . . . . .
>> . ..... . . .. . . .... . .. . .
>> . . . ... . . . .. . .
>> . . . . . . ..
>
> .. . . . . . ... . . . . .
> . . . . ..
. . . . . . . . . .. . .. . . . . . . . . . . . . . .. . . . . . . . . ..
> .. . . . . . .
> . .. . .. .. ... . .. . ... .
> ...
>
> . . . . . . . .. . . ....
>
> . . . . . . . . . .. . ..
. . ... . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . ....
.. . . . ..
. . . .. . .. . . . ... . . . .. . .. . . .. . . . . . . . .. .. . ...
. . . .. . .. .
... . . . . . .. .... . . .
.. .. . . . . . ... .
.. . . . . . . . .. .. .
. . ....
. . . . . . . . .... .. . .. . . ..
. . . . . . . . . . . . ..
. . . . . . . . . . . . .. .... . . .. . . .. . . . . ..
. . ..... . . . . . ... . .. . . . . . . ...
. . . . . . . . .. . . . . .. . . . . .... . . . . . .. . .. ... . . . . ..
. . . . .. . .... . . . .. . .. . . .. .. ...
... . . . .... . . . . ..... . . . . . . . .. ....
................... . . ....... . . . . . . . . . . ... . . . ... . . . . . .. . . . . . . . .. .. . . . . . . . ...
.. ..
news:DEAC0B5D-DC0D-4198-BA42-B4E7329395B8@tzi.org
On Jul 23. 2012, . 14:28. DRAGE. Keith (Keith) wrote:
> . . . . . . . . . . . . . . . ..
+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:
> . . . . . . . . . . . . . . .
> . . .
>
> .
>
> . . .. .. . ... .. . . ..
>
>>> . . .. .. . ... .. . . . ..
>>>> . . . . . . . . . . . . .
>>>> .. ..............>
>>
>> . ..
>
>
>
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,
.
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,
. . .. . . . . . . . .
. . . . . . . . . . .. . .
. . . . . .. . . . .
. . . . .. ... . . . . . . . . .
. . .. . . . . . . . . . .
.. . . . . . . . . . ... . . . . .
. . . . . . . . . . . . . . .
. .. .. . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . .. ... . . . . .
. . . . . . . . .. .. . . .
. . . . . ... . . . . . . ..
. .. . . . . . . . . .. .
.... . . . . . . . . . . ...
. . . . . . . . . .. . . . .
. ... . . . . . ..
.................
.. . . . . . . . . . . . .
. . . . . .. . . . . . .
... . . . . . . . . . . . .
. . . . . .. . . .
. . . . . . . . ....
. . . . . . . . . . . . . . .
. . . . . .. . . . .
. . . . . . . . . . ..
. . . . . . . . . . . . . .
. . . . . . . . . ..
..
..
. .. . .. . . ... .. .. . .. . ....
........> ..
..
.'. . . . .. . . . . . . ..
. . . . . .'. . .. . . . . . . . .'. .
. . . . . . . . . ..
. . . . . .. . . . . . .
. . . . . . . ..
. . . . . . . . . . . . .
..
. . . . . . . . . . . . . . .
. ..
..
.
.. .........
............. . . . . . ...
.. .. . .. . ... .
.. . . .
.. . . . . . . . .
. . . ..
. . . . . . . . . . ... .
. . . . . . . . . .. . . .
. . . . . ..
. . . . . . . . . . . . .
. . . . . . . . . ..
. . . . . . . . . . . . .
. .. . . . . . .. . . ... . .
. . . . . . .. . . .
. . . . . . . . . .
. . . . . . ..
. . . . . . . ... .. . . .
. . . . . . . . . .. . .
.. . . . . . . . . .. . .
. . . . . . . . .. . . . .
.. . . ........>
. . . . . . . . . . . . . .
. . . . . . . . ..
..
. .. .
. . .
. . ...
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 . . .. . . . . . . ..****
>
> . . . . . .’. . .. . . . . . . . .’. . .
> . . . . . . . . ..****
>
> ** **
>
> . . . . . .. . . . . . . .
> . . . . . . ..****
>
> . . . . . . . . . . . . .
> ..****
>
> . . . . . . . . . . . . . . . .
> ..****
>
> ** **
>
> ..
> . ****
>
> ** **
>
> *..* ......... ...
> .......... *. . . *. . ...
> *..* .. . .. . ... .
> *..* . . .
> *..* . . . . . . . .****
>
> ** **
>
> . . . ..
>
> . . . . . . . . . . ... . .
> . . . . . . . . .. . . .
> . . . . . ..
>
> . . . . . . . . . . . . .
> . . . . . . . . . ..
>
> . . . . . . . . . . . . .
> . .. . . . . . .. . . ... . . .
> . . . . . .. . . . . .
> . . . . . . . . . .
> . . . . ..
>
> . . . . . . . ... .. . . . .
> . . . . . . . . .. . . .. . .
> . . . . . . .. . . . . . .
> . . . . .. . . . . .. . . .
> .......>
>
> . . . . . . . . . . . . . . .
> . . . . . . . ..
>
> ..
>
> . .. .
>
> . . .
> . . ...****
>
> ** **
>
> ** **
>
news:25428E776486D6F2DF98C25B@JcK-HP8200.jck.com
... Friday. . 06. . 00.28 .. . .
......> ..
> 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.
.
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
. 7/5/2012 6:02 PM, Paul Hoffman wrote:
> On . .. .. . ... .. . . ..
>
>> . . . . . . . . . . . . . . . . . .. . . . ... . . . .. . . ........ . . . . . . . . . . . . . . ..
>
> . . . . . . . . . . . . . ... . . . . ... .. . . . . . . . . . . ..
news:FEE0CA44-A470-434A-9F25-88089411D0A6@bbn.com
. Jul 20, 2012, at 11:56 AM, Dave Crocker wrote:
> On ..... ... .. . .. . ..
>> . . . .. . . . . . .. . . . . .. . . . . . . . . . .. . . ... . . . . . . . . . . . . ..
>
>
> . . . . . . . . ... ..
>
> ..
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
> . . . . . . . . . . .
> . . . ..
> . .. . . ..
> ............> . . . .
. . .
.
news:6.2.5.6.2.20120711154825.09f09be8@resistor.net
Hi Andreas.
. 06.41 11..... . . ..
>. . . .. . . .. . . . .
>. . . . ..
>
>. . . . . . .. . . . . . . . . . .
>. . . . ..
>.. . . .. . . .. . .. . . . . .
>.. . . . . . . . ..
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:
> . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . .
> . . .
>
> .
>
> . . .. .. . ... .. . . . ..
>
>> . . ... . . . . . .. . .
>> . . . . . . .. .
>> ................ . . ..
>>
>> .
>> . .
>>
>> . ..... .... ....... ..
>>> . . ... . . . . ... ... ..
>>>
>>>
>>> . . ... ... . . . . .
>>> .... . . .
>>> . . .
>>> . .
>>> . .
>>> . .
>>> . . ...................
>>> . . .
>>> . . .....
>>>
>>> ..
>>> . . . ... . ... .. . .
>>> . ... . . . . ... .
>>> . . . . .. . .. ... . . .
>>> . . . . . . . . . . . .
>>> . . . . . . .. . . . .
>>> . . . . .. . . . ..
>>> . . . . . . . . . .
>>> . . . . . ... . . . . .
>>> . . . . . . . . .
>>> . . . . . . . . . . .
>>> . . . . . ... . . . ... .
>>> ..
>>>
>>> . .. . . . . . . . . . ...
>>> . . . . . . . . . .
>>> . . . . . . . . . .
>>> . . . ... . . ... . .. . .
>>> . . . . . . . . .. . .
>>> . . . . . . . . . . . . . . . . .
>>> . . . .. . . . . ...
>>> . . . ... . . .
>>> . . . . ..
>>>
>>>
>>> . . . . . . . . ..
>>> ...........................
>>>
>>> ... . . . . . ..
>>> .............................
>>>
>>>
>>> ... . . . . . . ..
>>> ..............
>>>
>>> .
>>> ..... . .
>>> .........
>>> ...................
>>> ... .. .............
>>> . .................
>>>
>
>
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:
> . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . .
> . . .
>
> .
>
> . . .. .. . ... .. . . . ..
>
>> . . ... . . . . . .. . .
>> . . . . . . .. .
>> ................ . . ..
>>
>> .
>> . .
>>
>> . ..... .... ....... ..
>>> . . ... . . . . ... ... ..
>>>
>>>
>>> . . ... ... . . . . .
>>> .... . . .
>>> . . .
>>> . .
>>> . .
>>> . .
>>> . . ...................
>>> . . .
>>> . . .....
>>>
>>> ..
>>> . . . ... . ... .. . .
>>> . ... . . . . ... .
>>> . . . . .. . .. ... . . .
>>> . . . . . . . . . . . .
>>> . . . . . . .. . . . .
>>> . . . . .. . . . ..
>>> . . . . . . . . . .
>>> . . . . . ... . . . . .
>>> . . . . . . . . .
>>> . . . . . . . . . . .
>>> . . . . . ... . . . ... .
>>> ..
>>>
>>> . .. . . . . . . . . . ...
>>> . . . . . . . . . .
>>> . . . . . . . . . .
>>> . . . ... . . ... . .. . .
>>> . . . . . . . . .. . .
>>> . . . . . . . . . . . . . . . . .
>>> . . . .. . . . . ...
>>> . . . ... . . .
>>> . . . . ..
>>>
>>>
>>> . . . . . . . . ..
>>> ...........................
>>>
>>> ... . . . . . ..
>>> .............................
>>>
>>>
>>> ... . . . . . . ..
>>> ..............
>>>
>>> .
>>> ..... . .
>>> .........
>>> ...................
>>> ... .. .............
>>> . .................
>>>
>
news:5005EC6A.8030805@qualcomm.com
On 7/17/12 5:14 PM, John C Klensin wrote:
> ... .. . .. . ... .. . .
> ......> ..
>
>
>> . ... . . . .. . . ... . .
>> . . . . . . .. . . . .
>> . . . . . . . . . .
>> . . . . . . . .
>> . .. . . . . . . . . .
>> . . . . . . . . .. . .
>> ... . . . . . . . . . .. .
>> ... . . ..
>>
> . . . ....
>
> . . .. . . . . . . .
> . . .. . . . . . ..
> .. .. . . . . . . .
> . . . . . . .. .
> .. . . . . . . . . .
> . . . . . . . . .
> . . . . . . .. .
> . . . . . . ...
>
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:
> . . . . . . . . . . . . . .
> .. . . . ..... . . . ..
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:
> >
> > . . . . . . . ... . . . ..
> >
>
> . . . . . . . . . . . .. ..
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.
> .. . . . . . . . . . . ..
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.
> .. . . . . . . . . . . . . . . .. . . . . . . . . . ..
>
> . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
>
> .
> .
>
> .. . . . . . . . .. . .. . . . . . . . . . . . . . . . . . ..
news:1342857902.7688.13.camel@gwz-laptop
. Sat, 2012-07-21 at 01:30 +0000, Fred Baker (fred) wrote:
> On . .. .. . ... .. . . ..
>
> > . . . . .. ... . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . ..
>
>
> . . . . . . . . . ....
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
>> ... . . . . . . . . . . .
>> . . . . . . . . . . ..
>
>. . . . . . . . . . .... . .
>. . . . . .. . . .
>. . . . . .. . . . . . .
>. . . . . . . . . ..
>. ..
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:
> . . . . . . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . .. . . . ..
>
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
>
> . .
> . . .
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:
>
> ..
>
> . . . . . . . . . .. . .
> . . . . . . . .. . .
> ..
>
> .
>
> . .. .
> . . .. . . . .
> . .
> .. .. ..... .. .. .....
> .... ..... .. ...........
> .. .
>
>
> . .. . . .. .. . .. . .... ..
>
>> . ..
>>
>> .. . . . . . . . . . . . ..
>> . . . . . . . . . . . . ..
>>
>> . . . . . . . .. . ..
>>
>> ..
>> .
>>
>>
>>> ...... ......
>>> .. ....... ........... . .
>> . . .
>>> .
>>> .. .. . .. . ... .
>>> .. . .
>>> .. .. . .. .......
>>> .. . . ... . .
>>>
>>>
>>> . . . . . . . . . . .
>>> . .. . . . . ..
>>>
>>> . .. . .. . .. . .. . .
>>> .. .. . . . . .
>>> . ..... . .. . ..
>>>
>>> .. ... . . . ... . . . . .. ..
>>> . . . .. . . . .. .
>>> . ...
>>>
>>> . . . . . . .. .. . . . . . . .
>>> . . . .. . . ..... . . . . ..
>>>
>>> ..............
>>>
>>> . . . . . . . . . . . . . .
>>> . . . . . . . .. . . . . .
>>> . . . . . . . . . . . .. .
>>> .. . .... . . . . . . . . . . . .
>>> . . ..
>>>
>>> . .. .. . . . . ...
>>> . .. . . .. . ..
>>> .........
>>>
>>> .... . . . . . . . . . .. ..
>>> . . . ..
>>>
>>> . . . . .. . . . . . . . . ..
>>>
>>> .
>>>
>>>
>>>
>>> . .. .
>>> . . .. . . . .
>>> . .
>>> .. .. ..... .. .. .....
>>> .... ..... .. ...........
>>> .. .
>>
>>
>
--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:
> . . . . . .. . . .. . . . . . . .. . . . . . . .. . . . . . . . ..
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.
.
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:
>
> . . . . . . . . . . .
> . .. . . . . ..
>
> . .. . .. . .. . .. . .
> .. .. . . . . .
> . ..... . .. . ..
>
> .. ... . . . ... . . . . .. ..
> . . . .. . . . .. .
> . ...
>
> . . . . . . .. .. . . . . . . .
> . . . .. . . ..... . . . . ..
>
> ..............
>
> . . . . . . . . . . . . . .
> . . . . . . . .. . . . . .
> . . . . . . . . . . . .. .
> .. . .... . . . . . . . . . . . .
> . . ..
>
> . .. .. . . . . ...
> . .. . . .. . ..
> .........
>
> .... . . . . . . . . . .. ..
> . . . ..
>
> . . . . .. . . . . . . . . ..
>
> .
>
>
>
> . .. .
> . . .. . . . .
> . .
> .. .. ..... .. .. .....
> .... ..... .. ...........
> .. .
>
news:39B73AD9-4E8F-4E94-A538-69BE5D8C0E18@gmx.net
Just a minor comment on this one.
On Jul ., .. at 8.20 AM. SM 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?
news:B69FC36D-4EE1-4132-9E43-D730093DD9AD@vpnc.org
. Jul ., 2012, at 9.56 .. Melinda Shore ..
> ... . . . . . . . ... .
> . . . . ..
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 . . . . . . . . . .. . . . . . . . . . ..
>>
>> . . . . . . . . . . . . . .
>> . . . . . . . . . . . . . . . .
>> . . . . . . . . ... . . . . .
>
> . . . . ... . . . . . . . .. . . . . . ..
>
> ..
> . .. ...... . .. . .
> .. . . ... . .. ..
news:5006DC70.7000500@bbn.com
.
>> ... .. . . . . .. . . ...
>>
>> . . . . . . . . ... . . . . . . . . . . . . . . . . .. . . . . . . . ... . . . . . . . . . . . ... . ..
In X.509 each cert can contain . . OID . indicates . 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 . relying . 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:
> . . . . ... . . . . . . . . . . . .
> . . . . . . . . ..
>
> ..
> .
>
> . .. . .. . . ... .. . . ... ......> ..
>>
>> . . .. .. . ... .. . . ..
>>
>>> . ..... ... . . . . ..
>>>> . . . . . . . . . . . . . .
>>>> . . . ..
>>>>
>>>> . . . . . . . . . . . .. . . . ..
>>>>
>>>> . . . . . . . . . . . . . . . . .
>>>> . . . . . . . .. . . . .....
>>>> . . . ..
>>>
>>> . . . . . . . . ..
>>>
>>> . ... . . . . . . ....
>>
>> . . . . . . . . .. . . . . . . . . ..
>>
>> .. . . . . .. . . . . . . . . .. . . .. .. . . . .. . . .. . . . . . . . . .. . . . . . ..
>>
>> . .. . . . . . . . ..
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:
> . .. ..
>
> . . . . . . . ..
> ..... . . . . . . . . . . .
> ..
> . . . . . . . . . . . . .
> . . . ..
>
> ..
> .
>
>
>> ...... ......
>> .. ....... ........... . .
> . . .
>> .
>> .. .. . .. . ... .
>> .. . .
>> .. . . .
>> .. .. ...... . . . . .
> . . .
>> ..
>>
>> . . . . . . . . . . . .
> .. . .
>> . . ..
>>
>> . . . . . . . . . . . . . .
> . ..
>>
>> .
>>
>>
>> . . .. .. . ... .. . . ..
>>
>>>
>>> . . . . . . ....
>>>
>>> .....................
>>>
>>>
>
news:5009BADF.9030602@bogus.com
On 7/20/12 12:42 . Mary Barnes wrote:
> .. . . .
> . . . . . . . . . ..
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:
>
>> . . . ..... . . . . . . . . . ..
>
> .. . . . . . . .. . . . .. . . .
> . . . . . . . . . . . . . . ..
>
> . . . . . . . ..
> . . . . . . . . . . . . . ..
> . . . . . . . . . . . . . . ..
>
> .....
>
news:6.2.5.6.2.20120730101231.047f2550@resistor.net
Hi Hannes,
At 12:19 PM 7/29/2012, Hannes Tschofenig wrote:
>. . . . . .. . .. .. .
>. . . . .. . . . .
>. . ..
>
>. . . . . . ..
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:
>
> . . .. .. . ... .. . . ..
>
>> ... . . . . . . . . . . . . . . .
>> . . . . . . . . . .. . . .. .
>> . . . . . . . . . . . . . .
>> . .. . . . . . . . . . ..
>
> . . .. . . .. . . .. . . . . . .. . . . . . ... . . . ... . . . . . . .. . . . . . . . . .. . . . . . . . ..
>
> . . . . .. . . . . .. . . . . . . . . . . . ..
>
> .
news:m2vch3sy8v.wl%randy@psg.com
> ... . . . . . . . .. . .
> . . . . . . . . . . .
> . ..
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, . Jul . 13.59:43 .0700
SM <sm@resistor.net> 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.
> . . ....
>
> .. . . . . . . ..
> . . . . . . .....
>
> . . . . . . . .... . .
> . . . . . . . ..
I think that will make parsing harder, and give no benefit at all.
Cheers,
Andreas
news:alpine.BSF.2.00.1207221550590.17748@joyce.lan
>> . . . . . . .. .... . . ..
>> . . . . . . . . . .. ... . . .
>> . . .. .... . . ... .. . ... . .
>> . . . . . . . ....
>
> . . . . . . . .. . . . . . .
> .. .. . . .. .
> . . . . . . . . ..
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>:
>>>>>> ".. .. . . ..........> ..
>
> .> .. . ... . . . . ... . ....
>
> .> . . . . . . . . . . . .
> .> . . . . . . ... . . .
> .> . . . . . . . . ..
>
> . ... . . .. . . . . . . .. ... . .
> . . . . . . . . ... . . . . . . .
> . .. . . . . . . . . .
> . . .. .. ... . . . .
> .. . . . . . . . . . . . .
> . ..
>
> . . . . . . . . . . . .
> .. . . . .. ... . . . . . ..
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab
news:1342921093.7688.90.camel@gwz-laptop
. Sat, 2012-07-. at 13:25 -0700, Martin Thomson wrote:
> On 21 . . .... . . ......> ..
> > . . . . .. . . . . .. . . . . . . . . . . . ..
>
> . . . . . . . . ..
How?
news:CAPv4CP95Rhma3reOvrWfrWQE_mqsyY8bL2EvkZq5hD6gbyf_ow@mail.gmail.com
On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> . ..
>
> . . . . . ... . . . . . . . .
> . . . .. .. . . . . .
> . . . . . . . . . . . .
> . ..
>
> . .. . ..
>
> ..
>
> . ..
>
> . . . . . .. . ..
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:
> . ..
>
> . ...... . .... . . ..
>
>> ..
>>
>> . . . .. ... . . . . .. . . . . . . . . ..
>>
>> . . . . . . . . . . .. . . . . . . . . . ..
>
> . . . . . . .. . . . . . . . . . . . . . ..
>
> .... . . .
>
> . . . . . . . . . .
> . . . .. . .. . . .
> . . . . . . . . . . .
> . . . . .. . . . . .
> . . . . . . . . . . . .
> . . . . . . .. .... .
> .. . .. . . ..
>
> ...... .
>
> . . . . . . . . .
> . . . . .. . . ..
>
> . . . . . . . . . . . . .
> . ..
>
> . . . . . . . . . .
> .. . . . . . . . . ..
>
> . . . . . . ..
>
> . . . . . . . . . . .
> ..
>
>
> .
>
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, . what . be the practical way . do that?
news:C023E9BE-5183-4A36-8470-B206FFBF1746@cdt.org
Hi Andreas.
On . 10, ., at 7.. AM, Andreas Petersson ..
>> . . . . . . .. . . . . . . .
>> . . . . . . . . .
>> . . . . . . . . . . . .
>> . . ... . . . . . . . .
>> . ... ..
>>
>> ... . . . . . . . . . . . . . . . . ..
>>
>> .. . . . ... . . . . . . . . ..
>>
>> .. . . . . . . . . .
>> . .. . . . ... . .. . . ..
>> . . . . . . . . . . . . ...
>>
>> . . . . . . . . . . . . . ... . ..
>
> . . . . . . . . . . . . ..
>
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
>
> ..
> .
news:CC3325CD.12C8B%d.malas@cablelabs.com
+1
On 7/23/12 6:28 AM, "DRAGE, Keith (Keith)"
<keith.drage@alcatel-lucent.com> wrote:
>... . . . . . . . . . . . .
>. . ..
>
>. . . . . . . .. . ... . . .
>. . .. . . . . . . . . . . .
>. . . . . . . . . . . .
>. . . . . . . . . . . ... .
>. . . . . . . . . . . . .
>..
>
>. . . . . . . . . . . .. . .
>. . . . . .. . . . . . .
>.. . . . . . .. . . . . . ..
>. . . . . . . .. . . . .
>. . . . . . .. . . . . . .
>. . . . . . . . . . . . .
>..
>
>. . . . .. . . . . . . . . . . .
>. . . . . . . . . .. . . .
>. . . . . . . . . . .
>.. . . . . . . . . . . . . . .
>. . . ..
>
>.
>
>.... . . . . . . . . . . .
>.. . . . . . . . . . . .
>. . . . . . . . . ..
>
>> ...... ......
>> .. ....... ........... .
>> . . . . .
>> .. . . . ...
>> .. . . .
>> .. ...... ...... ...... .....
>> .. . . . . .
>>
>> . . . . . . . . . . . .
>>.
>> .
>> . . . ..
>>
>> . . . . . . . . . . . .. . .
>>.
>> ..
>>
>> . . . . . . . . . . . . . . .
>> . .
>> . . . . . . . .. . .
>>.
>> .....
>> . . . ..
>>
>> . .
>> . . .
news:62E31CBF-190F-4FB3-94FC-1CEB318F6C84@gigix.net
. Jul 20, 2012, at 18:36 , Joel jaeggli wrote:
> On ..... ... . . . . ..
>> . . . . . . . . . . . . . .
>> . . . ..
>>
>> . . . . . . . . . . . .. . . . ..
>>
>> . . . . . . . . . . . . . . . . .
>> . . . . . . . .. . . . .....
>> . . . ..
>
> . . . . . . . . ..
>
> . ... . . . . . . ....
>
True, but if I can choose I would say 20-25 is better...
L.
>> . .
>> . . .
>>
>
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:
> . ..... .... . . ..
>> . . ............> . . . . . .. . . . . . . ..............>.
>>
>> . . . ..............> . . . . . . . ..
> > ...
>
> ..
news:500A572C.3020003@gmail.com
. 21/07/2012 02:30, Fred Baker (fred) wrote:
> On . .. .. . ... .. . . ..
>
>> . . . . .. ... . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . ..
>
>
> . . . . . . . . . ....
(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, . . wrote.
> . . . . . ... . . .... . .
> . .
> . . . . . . . . . . . . ..
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 |
| . | 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:
> . .. ..... . ... ... . . ..
>
> > . . . . .... . . ......> ..
> > > . . . . .. . . . . .. . . . . . . . . . . . ..
> >
> > . . . . . . . . ..
>
> ..
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.
.
. .. .
. . .. . . . .
. .
.. .. ..... .. .. .....
.... ..... .. ...........
.. .
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:
> . . . . . . . . . . . .. .. . ... . . . . . . . . . . . . . . ..
>
> . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . ... . . . . ..
>
> . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
>
> . . .. .. . ... .. .. . . ... ..
>
>>> .. . . .........
>>>
>>> . . . . . . . . . . ..
>>
>> ... . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. .. . . . . . . . . . ... . . . ..
>>
>> .
>
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:
> ..
>
> . ... . . .. . . . . . . . .
> . . . .. . . . .. ...
> . . . . . .. . . . . .
> . ... . . . . . . .
> ... . ...
>
> ... . . . ... .
>
> . . . . . .. . . . . . . .
> . . . .. . . . . .
> . . . .. . . . .. . . .
> . . . . . . . . . . .
> . . . . . . . . .. . .
> . . . . . . .. . .
> . . . . . . .. . . .
> ...
>
> . ... . . ..
>
> .
>
> . ..... .... . . ..
>> ..
>>
>> . . . . . . . . . . ..
>> ...
>>
>> ..
>>
>> . ..... .... . . . ..
>>> . . . . . . . . . . . . . .
>>> . .
>>> . . . . . . . . . . . . . .
>>> . .
>>> . . .
>>>
>>> .
>>>
>>> . . .. .. . ... .. . . . ..
>>>
>>>> . . ... . . . . . .. . .
>>>> . . . . . . .. .
>>>> ................ . . ..
>>>>
>>>> .
>>>> . .
>>>>
>>>> . ..... .... ....... ..
>>>>> . . ... . . . . ... ...
>>>>> ..
>>>>>
>>>>>
>>>>> . . ... ... .
>>>>> . . . .
>>>>> .... . . .
>>>>> . . .
>>>>> . .
>>>>> . .
>>>>> . .
>>>>> . .
>>>>> ...................
>>>>> . . .
>>>>> . . .....
>>>>>
>>>>> ..
>>>>> . . . ... . ... .. . .
>>>>> . ... . . . . ... .
>>>>> . . . . .. . .. ... . . .
>>>>> . . . . . . . . . . . .
>>>>> . . . . . . .. . .
>>>>> . .
>>>>> . . . . .. . . . ..
>>>>> . . . . . . . . . .
>>>>> . . . . . ... . . . .
>>>>> .
>>>>> . . . . . . . . .
>>>>> . . . . . . . . . . .
>>>>> . . . . . ... . . . ... .
>>>>> ..
>>>>>
>>>>> . .. . . . . . . . . . ...
>>>>> . . . . . . . . . .
>>>>> . . . . . . . . . .
>>>>> . . . ... . . ... . .. . .
>>>>> . . . . . . . . .. . .
>>>>> . . . . . . . . . . . . . . . . .
>>>>> . . . .. . . . . ...
>>>>> . . . ... . . .
>>>>> . . . . ..
>>>>>
>>>>>
>>>>> . . . . . . . . ..
>>>>> ...........................
>>>>>
>>>>>
>>>>> ... . . . . . ..
>>>>> .............................
>>>>>
>>>>>
>>>>>
>>>>> ... . . . . . . ..
>>>>> ..............
>>>>>
>>>>> .
>>>>> ..... . .
>>>>> .........
>>>>> ...................
>>>>> ... .. .............
>>>>> . .................
>>>>>
>>>
>>
>
--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:
> . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . . . . . . . ..
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.
> . . . . . . . . . . . . . . . . ..
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:
> . ..
>
> . . .. .. . .. . . . . . . . . .. . .
> ... . . . . . . . . . .
> . . .... . . . . . . . . . .
> . . . . .. . .. .. . .. . .
> . . . . .. . . . .
> . . . ..
>
> ......................................................................................................
> .>.> . . . . .. .
>
> . . . .. . . . .. . . .
> . .. . . .. . . . . .
> . . . . . ..
> ......................................................................................................
> .>. .> . . . . . . . .
>
> . . . . . . . . . . .
> ... .. . . . . . ...
> . .. . . . ... . . . .
> . . . .. . . ... . . . .
> . . . . . .. . . . .
> . . . . . .. . . . . . . .
> . . . ... .. . . . .. .
> . .. . . . . . . . . . .
> . . . ...... . . . . . . .
> . . . . ... . . . . . .
> .. . . . . . . . . . .
> . . .. . . . . . ...
> . . . .. . . . . . . .
> ... . . .. . .. . ... .
> . . . . . ..
> ..................................................................................
> .>. .>
>
> . . . . .. . . . . .
> . .. .. . ..
> ...................................................................................
> .> . .> . . ... . . . . .. .
>
> . . . . .
> ....... . . .. . . . . .
> . . ................ . . . . .
> . . . . . . ..
> ...................................................................................
>
> . . . . . . . . . . . . ..
> . . . . . . . ... . . . . . . .
> . . . . . ..
>
> .
>
> . .
> . . .. .
> ..................................
>
>> . . . . . . . . . . . .
>> . . . . . . . ..
>
>> .
>
>
>> . .. . .. . . ... .. . .
>> ......> ..
>>> . ..
>>>
>>> . . . . . ... . . . . . . . .
>>> . . . .. .. . . . . .
>>> . . . . . . . . . . . .
>>> . ..
>>>
>>> . .. . ..
>>>
>>> ..
>>>
>>> . ..
>>>
>>> . . . . . .. . ..
>>
>> . ... . . . . .. . . . . . .
>> . . . .. . . . . . . . .
>> ..
>>
>
>
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]
>
> [...] . . ... . . . . . . .
> . . . .. . .. . . . . .. . .
> . . . . ..
>
> . . ... . . . . . . . ..
> [...]
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:
> . .. ..... . ... ... . . ..
>>
>> >
>> > . . . . . . . ... . . . ..
>> >
>>
>> . . . . . . . . . . . .. ..
>
> . .. .. . . . . . . . .. . . . . . . .. . . . . ... . ... . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . . .. . .. .. . . .. . ... . . . . ..
>>
>> .. . . . . . . . . . . ..
>
> . ... .. . . . .. . . . . . .. . .. .. . . .. . ... . . . . ..
>
>> .. . . . . . . . . . . . . . . .. . . . . . . . . . ..
>>
>> . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
>>
>> .
>> .
>>
>> .. . . . . . . . .. . .. . . . . . . . . . . . . . . . . . ..
>
news:50186301.9030506@levkowetz.com
On 2012-07-31 14:35 Steven Bellovin said the following:
> . . . . . . . . . . .
> .. . ... . . . . . . . . . .
> . . . . . . . . . . . .. .
> .. . . . . . . .. .. . ..
> . . ... .. .. ... . . . .. .
> .. . . .. . . . . . .
> . . . .. . . . ... ..
Ah. I'll have to look at fixing cases like the ones you mention, then.
Thanks!
Henrik
>
> . . .. .. . ... .. . . ..
>
>>
>> ..
>>
>> . . . . . . . . . .. . .
>> . . . . . . . .. . .
>> ..
>>
>> .
>>
>> . .. .
>> . . .. . . . .
>> . .
>> .. .. ..... .. .. .....
>> .... ..... .. ...........
>> .. .
>>
>>
>> . .. . . .. .. . .. . .... ..
>>
>>> . ..
>>>
>>> .. . . . . . . . . . . . ..
>>> . . . . . . . . . . . . ..
>>>
>>> . . . . . . . .. . ..
>>>
>>> ..
>>> .
>>>
>>>
>>>> ...... ......
>>>> .. ....... ........... . .
>>> . . .
>>>> .
>>>> .. .. . .. . ... .
>>>> .. . .
>>>> .. .. . .. .......
>>>> .. . . ... . .
>>>>
>>>>
>>>> . . . . . . . . . . .
>>>> . .. . . . . ..
>>>>
>>>> . .. . .. . .. . .. . .
>>>> .. .. . . . . .
>>>> . ..... . .. . ..
>>>>
>>>> .. ... . . . ... . . . . .. ..
>>>> . . . .. . . . .. .
>>>> . ...
>>>>
>>>> . . . . . . .. .. . . . . . . .
>>>> . . . .. . . ..... . . . . ..
>>>>
>>>> ..............
>>>>
>>>> . . . . . . . . . . . . . .
>>>> . . . . . . . .. . . . . .
>>>> . . . . . . . . . . . .. .
>>>> .. . .... . . . . . . . . . . . .
>>>> . . ..
>>>>
>>>> . .. .. . . . . ...
>>>> . .. . . .. . ..
>>>> .........
>>>>
>>>> .... . . . . . . . . . .. ..
>>>> . . . ..
>>>>
>>>> . . . . .. . . . . . . . . ..
>>>>
>>>> .
>>>>
>>>>
>>>>
>>>> . .. .
>>>> . . .. . . . .
>>>> . .
>>>> .. .. ..... .. .. .....
>>>> .... ..... .. ...........
>>>> .. .
>>>
>>>
>>
>
>
> ... .. ..............
>
>
>
>
>
>
news:E14BAB4D-5F34-4800-A660-29026D225EB5@cs.ucla.edu
On Jul 20, 2012, at 9:06 AM, IETF Administrative Director wrote:
> . . . . . . . . . . . . . .
> . . . ..
>
> . . . . . . . . . . . .. . . . ..
>
> . . . . . . . . . . . . . . . . .
> . . . . . . . .. . . . .....
> . . . ..
>
> . .
> . . .
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-.. Pete Resnick ..
>. ... . . . .. . . ... . .
>. . . . . . .. . . . .
>. . . . . . . . . .
>. . . . . . . . . ..
>. . . . . . . . . .
>. . . . . . . .. . . ...
>. . . . . . . . . .. . ... . . ..
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
. 07/03/12 05:51, Eggert, Lars wrote:
> On . .. .. . .... . . ..
>> . . . . . . . . . . . . . . .. . . . .
>> . . . . . . . . ..
>
> ..
>
> . . . . . . ... . . . ..
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:
> ..
>
> . . . . . . . . . . . . .....
> .. . . . . . . . . . . .
> . . .. . . . . . . . . .
> . . .. . . . .. . . . ..
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.
> .
>
>
> . . .. .. . ... .. .. . .. . .... ..
>
>> . .. ..
>>
>> . . . . . . . .. ..... . .
>> . . . . . . . . . ..
>> . . . . . . . . . . . .
>> . . . . ..
>>
>> .. .
>>
>>
>>> ...... ...... .. .......
>>> ........... . .
>> . . .
>>> . .. .. . .. . ... . .. . .
>>> .. . . . .. .. ...... .
>>> . . . .
>> . . .
>>> ..
>>>
>>> . . . . . . . . . . . .
>> .. . .
>>> . . ..
>>>
>>> . . . . . . . . . . . .
>>> . .
>> . ..
>>>
>>> .
>>>
>>>
>>> . . .. .. . ... .. . . ..
>>>
>>>>
>>>> . . . . . . ....
>>>>
>>>> .....................
>>>>
>>>>
>>
>
>
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:
>
>
> ... .. . .. . ... .. . .
> ......> ..
>
>> ..
>>
>> . . . . . ..... . . . .. . . .
>> . . . . . . . .. . . .. . . .
>> . . . . .. . . . . . .
>> ..... . . . . . . . .
>> .
>>
>> . . . . . .. . .. . . . . .
>> .. . . . . . ... .. .
>> . . .... . . . ......
>> .........................
>
> ..
>
> ... . . . . . . . . . .
> . . . . .. . . . . . ..
> >. . . . .. . . . . . . . .
> . . . . . . .. . . . . .
> . .. . ... . . . . . .
> .. . . . . ... . . . .... ... .
> . . . . . . . . . . . . . .
> . . . . . . . . ... .
> ..
>
> . . . . . . . . . .
> . . . . . . .. . . .
> . .. . . .. . . . . . .. .
> .. . . . . . . .. . . .
> . . . . .. . . . . . .
> . . . . .. . . . . .
> . . . . . . . . . . . .
> . . . . . . . . .. ... . . .
> . . . ... . . . . . .
> . . . . . . . . . . .
> .. . . ... .. . . . . .
> . . . . . . . . . . .
> .. . . . . . . . ... . .
> . ... ..
>
> .. . . . . . ... .. ... . . .
> . . . . . ..
>
> ..
> .
>
>
news:20120722160435.68743.qmail@joyce.lan
> . .. . . . . . .
> . . . . .. . . . . ..
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:
> . . . ... . .. .. ..... . .
> . . . . . . . . . . .
> . . . . . . . ..
..
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:
> . . . . . . . . . . . . . . . . . .. . . . ... . . . .. . . ........ . . . . . . . . . . . . . . ..
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
. . . . . . . . . . . . . .
.
. . . . . . . . . .
. .
. . ..
. . . . . .. .. . .
.
. . . . . . . . . . .
.
. . .. . . . . . .. . . . . .
. . .
. . . .. . . . . . . .
. . .
. . . . . ..
. . . . . . . . . . .. . ..
. .
. . .. . . . . . . .. . .
. .
. . . . . . .. . . . . . .
. . ..
. . . . . . . . . . ..
. . . . . . . . . . . . .
. .
. . . . ..
. . . . . . . . . . . . .
.. ..............>
. . . . . . . . . . . . .
.
.. . . . ..... . . . ..
. .
. . .
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:
>.. . . .. ..
>
>. ... . . .. . . . . . .
>. . . . . . ..
>
>
>. . .. . . . . . . . . .
>. . . ..
>
>. . . . . . . . ... . . .
>. . .. . . . . . . . .. . .
>..
>. .. . . . .. . . . .. .
>. . . . . . . . . . . .
>. . . .. . . . . . . ..
>. . ..
>. . . . . . .. . . . .
>. . . . .. . . . . . . . .
>. . . . . . . . . . . .
>. . ..
>
>
>. . . . . . . . .. . . . .
>. . . . . . . .. . . . .
>. .. . . . . . .. . . . ..
>. . . . . . . . . . .. . .
>. . . . . . . . . .. . .
>. . . . . . . . . . .
>. . . .. . . . . . . . . . . . .
>. . . . . . . . . . .. . .
>. . . . . . . . . .
>. . . . . . . ..
>
>
>..
>. .
>. . . . ...
>.....
>........
>
>
>
>
>
>. ..... ... .. .. .. ........> ..
>
>>.. ..
>>
>>. . . . .......... . . .
>>. . . . .. . ..
>>
>>. . . . . . . .. . . ..
>>
>>. . . ......
>>
>>..
>>.
>>
>>
>>........ . . ........
>>.. .. . ... . .
>>............ .. . . ..
>>. . .. . . . ..... ..
>>. . . . ........>
>>. . . . ........>
>>. . . . . ......>. ..........>.
>>................>
>>
>>. .. ..
>>
>>. ..... ... .. . . ..
>>> . ..... .... . . . . .
>>>>> . . . . . . . . . . . ..
>>>>>...
>>>>> . . . . . . ..
>>>>
>>>> . . . . . . . . . . . . . . .
>>>> . . . . . . . . . .. . ... . .
>>>>.
>>>> . . . . . . . . . . ..
>>>>
>>>> . . . . . . . . . .. . .
>>>>.
>>>> . ... . .. . . ... . . . . .. . .
>>>> . . . . . . . . ..
>>>>
>>>> . . ..
>>>> . . . . . . . . . . ... . .
>>>> . . .. . . . . . . . . ..
>>>>.
>>>> . . . . . ..
>>>>
>>>> . . . . . ... . .
>>>> .... . . . . . . . . . .
>>>> . . . . . . . . ..
>>>>.
>>>> . . .>
>>>> .... . . . . . . . . . . .
>>>>.
>>>> . . . ..
>>>> .. . . . .>
>>>
>>> . . . . . . .... ... . . . .
>>> ..
>>>
>>> . .. . . . . . ..
>>>.
>>> . .. . . . . . . .
>>
>>. . . . . . . . . .
>>.. . . .. . . . . . . . .
>>. . . ..... ... . . .. . . .
>>. . . . . ..
>>
>>. . . . . . . . . . . . . .
>>. ..
>>
>>
>>>
>>> . .. . .. . . . . . ..
>>
>>.. . . . . .. . . . .. . . .
>>. . . ..
>>
>>>
>>> . . . . . .. . .. . . . .
>>> . . .....
>>>
>>> . . . . . . . . . .
>>>.
>>> . . . ............
>>>
>>> . . .....
>>>
>>> . . . . . . . . .
>>> ............
>>>
>>> .. . . . . .. . ... . . .
>>> . . ...
>>
>>. . . . . . . . . . . . . . .
>>. . .. . . . ..
>>
>>. .. . . . . . . . . .. . .
>>. . . .. . . . . . . . ... .. .. .
>>. . ..
>>
>>. .. . . . . . . . .. .
>>. . .. . . . ..
>>
>>.. . . . . . . . . . . . ...
>>. . . . . . . . . . .
>>. . ..
>>
>> .
>>
>>..
>>.......
>>
>>. . . . . . . . . .
>>. .. . .. . . .. . . .
>>. . . .
>>
>>
>>_______________________________________________
>>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 . 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 . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
>
> . . . . . . . . . . . . .. . . ... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. .. .. .. . .. . . . . . . . . ... .. . . . . . . . .. . . . . . . . . . . . ..
> . . ... .. . .. . . . . ..
> .. . . . . .
> . . . . . . . .. . . . . . .
> . . . . . . . . .
> . . ...
>
> .. . . . . . ..
> .. . . . . . . . . . ....
> . . . . . ...
> . . . . . . . . . . .. .. . . . . . . .. . . . . . . . . ..
> . . . .. . ... . . . . . . . . . . . . . ..... . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . ... .. ... . . . . . . . . . . . ... .. . ... . . . . .....
>
> ... . . . . . . . . . . . . . ... . .. . . ... . ... . . . . . . . . ... . . . . . . ... .. . . . . . . . . .. . . . . . ... . .. . .. . . . . . . . . . .. . . . . . . .. . ... . . . . . . . .. . . . . . . . . . . ..
>
> ..
>
> . .. . . . . . . . .
..
DTN made easy. lean. . smart ..> ....postellation.viagenie.ca
NAT64.DNS64 open.source ..> ....ecdysis.viagenie.ca
STUN.TURN server ..> ....numb.viagenie.ca
news:tsleho8j8wn.fsf@mit.edu
>>>>> "Stephen" == Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
Stephen> .. . ... . . . . ... . ....
Stephen> . . . . . . . . . . . .
Stephen> . . . . . . ... . . .
Stephen> . . . . . . . . ..
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 . believe today we do intend . publish the
. ..
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:
> . . . . . . . ... . . . . .
> .. .
> . . . .. ..
>
> . ... . . . .. . . . . .
> .. .
> . . . . .. . . . . . . .
> . . .
> . .. ..........>
>
> . . . . . . . . .. .
> ..........>
>
> . . . . . .. . . . . . .
> . ..
> . . . . . .. . . . . .
> . . .
> ..
>
> . . . . . . . .. . .
> . .
> ..... <javascript:;>. . . . . .. .
> ............
> ...>
>
> . . . . . ..
>
> . . . . . . . . . .. . . .
> . .
> . . . .. . ... . .
> .................> . .
> . ... . . . ..
>
> . .
> . . .
>
--
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:
> > . . .. .. . ... .. . . . ..
> >> . . . . . . . . . . . . .
> >> .. ..............>
>
> . ..
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:
> . ..
>
> . . .. .. . ... .. . . ..
> >> . . . . . . .. . . . . . . .
> >> . . . . . . . . .
> >> . . . . . . . . . . . .
> >> . . ... . . . . . . . .
> >> . ... ..
> >>
> >> ... . . . . . . . . . . . . . . . . ..
> >>
> >> .. . . . ... . . . . . . . . ..
> >>
> >> .. . . . . . . . . .
> >> . .. . . . ... . .. . . ..
> >> . . . . . . . . . . . . ...
> >>
> >> . . . . . . . . . . . . . ... . ..
> >
> > . . . . . . . . . . . . ..
> >
>
> . . . . ... . . . .. . .. . . . . . . . . . . . ..
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.
> . . . . . ... . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . .. .. . . . ... . . . . . . . . . . . . . . . . . . . . . .. . . . ... . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . ..
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.
. big issue here is that there is quite a lot of things that the end
user are aware of.
> The . . . . . . . . . . . . . . . . ... . . . .. . .. . . . . . . . .... . . ... . . . . . . ..
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.
..
.
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:
> .. . . . .. . . .. ..
>
> . . . .. . . . . . .. . . . . .. . . . . . . . . . .. . . ... . . . . . . . . . . . . ..
>
>
>
>
> . . .. .. . ... .. .. . ..
>
>> . . . . . . . . . . . . . . .
>> . . .
>>
>> .
>>
>> . . .. .. . ... .. . . ..
>>
>>>> . . .. .. . ... .. . . . ..
>>>>> . . . . . . . . . . . . .
>>>>> .. ..............>
>>>
>>> . ..
>>
>>
>>
>
--
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:
> . . ... . . . . . .. . .
> . . . . . . .. .
> ................ . . ..
>
> .
> . .
>
> . ..... .... ....... ..
>> . . ... . . . . ... ... ..
>>
>>
>> . . ... ... . . . . .
>> .... . . .
>> . . .
>> . .
>> . .
>> . .
>> . . ...................
>> . . .
>> . . .....
>>
>> ..
>> . . . ... . ... .. . .
>> . ... . . . . ... .
>> . . . . .. . .. ... . . .
>> . . . . . . . . . . . .
>> . . . . . . .. . . . .
>> . . . . .. . . . ..
>> . . . . . . . . . .
>> . . . . . ... . . . . .
>> . . . . . . . . .
>> . . . . . . . . . . .
>> . . . . . ... . . . ... .
>> ..
>>
>> . .. . . . . . . . . . ...
>> . . . . . . . . . .
>> . . . . . . . . . .
>> . . . ... . . ... . .. . .
>> . . . . . . . . .. . .
>> . . . . . . . . . . . . . . . . .
>> . . . .. . . . . ...
>> . . . ... . . .
>> . . . . ..
>>
>>
>> . . . . . . . . ..
>> ...........................
>>
>> ... . . . . . ..
>> .............................
>>
>>
>> ... . . . . . . ..
>> ..............
>>
>> .
>> ..... . .
>> .........
>> ...................
>> ... .. .............
>> . .................
>>
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:
> . .. . .. . . ..... ...
> . . ........> .
> . . . . . . ..
>
>> . . . . . . . . . . .
>> . .
>> ..............................>
>
> . . .. . . .. . . .... ..
>
> . . . . . . . . . ..
>
> .... . . . . .. . . . . . . . .
> ... . . . ...
news:6EC0C8C6-3071-4DFD-8F4C-779A08D94D1E@gmx.net
>
> . . . . . . . ... . . . ..
>
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
>
> . . . . . . . . . . . . .
> .
> . . . ..
>
> . . . . . . . . . . . .. . . .
> ..
>
> . . . . . . . . . . . . . . .
> . .
> . . . . . . . .. . . .
> .....
> . . . ..
>
> . .
> . . .
news:500CFF8E.1090905@cisco.com
On 22/07/2012 17:26, Melinda Shore wrote:
> On ..... ... .. . . ..
>> . .. . ..
>>
>> ..
>>
>> . ..
>>
>> . . . . . .. . ..
>
> .. . . . . . . . . . ...
> ..
>
> .
>
>
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:
> . . . . . . . . . . .. ...
> . . . . . . . . . . . . .
> . ..
I'd be a lot more comfortable with people describing/speaking up
for their own religious requirements.
> . .. . .
> . . . . . . . . .. . . .
> . ..
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,
>
> . . . . . . . . . . ..
> ...
>
> ..
>
> . ..... .... . . . ..
>> . . . . . . . . . . . . . .
>> . .
>> . . . . . . . . . . . . . .
>> . .
>> . . .
>>
>> .
>>
>> . . .. .. . ... .. . . . ..
>>
>>> . . ... . . . . . .. . .
>>> . . . . . . .. .
>>> ................ . . ..
>>>
>>> .
>>> . .
>>>
>>> . ..... .... ....... ..
>>>> . . ... . . . . ... ...
>>>> ..
>>>>
>>>>
>>>> . . ... ... .
>>>> . . . .
>>>> .... . . .
>>>> . . .
>>>> . .
>>>> . .
>>>> . .
>>>> . .
>>>> ...................
>>>> . . .
>>>> . . .....
>>>>
>>>> ..
>>>> . . . ... . ... .. . .
>>>> . ... . . . . ... .
>>>> . . . . .. . .. ... . . .
>>>> . . . . . . . . . . . .
>>>> . . . . . . .. . .
>>>> . .
>>>> . . . . .. . . . ..
>>>> . . . . . . . . . .
>>>> . . . . . ... . . . .
>>>> .
>>>> . . . . . . . . .
>>>> . . . . . . . . . . .
>>>> . . . . . ... . . . ... .
>>>> ..
>>>>
>>>> . .. . . . . . . . . . ...
>>>> . . . . . . . . . .
>>>> . . . . . . . . . .
>>>> . . . ... . . ... . .. . .
>>>> . . . . . . . . .. . .
>>>> . . . . . . . . . . . . . . . . .
>>>> . . . .. . . . . ...
>>>> . . . ... . . .
>>>> . . . . ..
>>>>
>>>>
>>>> . . . . . . . . ..
>>>> ...........................
>>>>
>>>>
>>>> ... . . . . . ..
>>>> .............................
>>>>
>>>>
>>>>
>>>> ... . . . . . . ..
>>>> ..............
>>>>
>>>> .
>>>> ..... . .
>>>> .........
>>>> ...................
>>>> ... .. .............
>>>> . .................
>>>>
>>
>
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