Re: Berlin was awesome, let's come again

[Livingood, Jason]

+1 


Very productive venue, easy to access city, several hotels near the venue
for alternatives, walkable area around the venue, lots of options for
restaurants, good public transit system, etc. And I enjoyed the social &
social venue as well (thanks DENIC)!

I really do hope we return in the future - this location really has many
of the things we as participants like.

Thank you very much to all of the sponsors and volunteers!!

Jason

On 8/2/13 12:58 PM, "Eggert, Lars"  wrote:

>Venue was great, food options here and in the city were great, all-around
>great experience. Let's come again!
>
>(I do kinda wonder how there wasn't a single local company willing to
>step up to be the host. That's embarrassing to me as a German, esp. if
>the IETF meets in the self-declared IT hub of Germany. Better luck next
>time, I hope.)
>
>Lars

Re: IAB Statement on Dotless Domains

[Livingood, Jason]

On 7/12/13 12:24 PM, "Phillip Hallam-Baker" 
mailto:hal...@gmail.com>> wrote:
Unfortunately the IAB is not going to give that advice. They seem to have 
passed on advising ICANN not to issue .corp which is going to be a total 
security meltdown.

The report at http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf is 
relevant here (though obviously it is an SSAC document and not an IAB document, 
which I think is part of the point you may be making).

It's not 20 pieces of silver at stake here is a quarter million bucks or more a 
pop.

FWIW, I think for most larger companies with multi-billion dollar revenues 
streams it is less about the up-front fees to apply & operationalize a gTLD 
than the long term business potential.

Jason

Re: IAB Statement on Dotless Domains

[Livingood, Jason]

There must be something similar to Godwin's Law whereby any IETF discussion can 
devolve into a debate over NAT. ;-)

Jason

On 7/12/13 10:13 AM, "Phillip Hallam-Baker" 
mailto:hal...@gmail.com>> wrote:

Keith, read my words, I choose them more carefully than you imagine.

solves their problems at negligible cost TO THEM
What part of that do you disagree with? I don't dispute the fact that NAT is a 
suboptimal solution if we look at the system as a whole. But the reason I 
deployed NAT in my house was that Roadrunner wanted $10 extra per month for 
every device I connected to a maximum of 4. I have over 200 IP enabled devices 
in my house.

Re: Sufficient email authentication requirements for IPv6

[Livingood, Jason]

On 3/29/13 12:58 PM, "John Levine"  wrote:


>>As a result, it is questionable whether any IPv6 address-based
>>reputation system can be successful (at least those based on voluntary
>>principles.)
>
>It can probably work for whitelisting well behaved senders, give or take
>the DNS cache busting issues of IPv6 per-message lookups.
>
>Since a bad guy can easily hop to a new IP for every message (offering
>interesting new frontiers in listwashing) I agree that it's a losing
>battle for blacklisting, other than blocking large ranges of hostile
>networks.

Agree. The IP blacklisting that worked well for IPv4 is completely
unsuited for IPv6 (I'd go as far as to say it is a complete failure, no
matter if you look at different size prefixes or not).

The only model that I personally can see working at the moment for IPv6 is
a mix of domain-based reputation and whitelisting. I like domain-based
better since it is managed by sending domains on a distributed basis.

Mail acceptance for IPv4 worked inclusively - receivers accept unless IP
reputation or other factors failed. IMHO with IPv6 that model may need to
be turned around to an exclusive one - so receivers will not accept mail
unless certain factors are met (like domain-based authentication or the
IPv6 address is on a whitelist). I'd expect MAAWG will continue to be a
good place for mail ops folks to work through this stuff.

- Jason

Re: travel guide for the next IETF...

[Livingood, Jason]

On 1/2/13 1:44 PM, "Donald Eastlake"  wrote:


>>Good... but how to get there?
>>
>> We appear to be stuck in the middle of a monster hotel with a single
>> boulevard and nothing at all nearby (except that there is a shuttle
>> to Disney)
>
>There are some things on the other side of World Drive.

Things like this? 
http://upload.wikimedia.org/wikipedia/commons/1/1c/Florida_Alligator.jpg

;-)

If anyone is into cars, the weekend the meeting starts is the Amelia
Island Concours D'Elegance from 8 March - 10 March. That is ~3 hours drive
north of Orlando. The show will be celebrating the 50th anniversary of the
Porsche 911 and Ford GT40. See http://www.ameliaconcours.org/

Jason

Re: Recall petition for Mr. Marshall Eubanks

[Livingood, Jason]

suppose = support (if you were an auto-correct program)


G...

On 11/4/12 5:59 PM, "Livingood, Jason" 
wrote:

>Same here. I'm noncom-eligible and suppose the recall.
>
>
>Jason Livingood
>
>On 11/4/12 11:45 AM, "Arturo Servin"  wrote:
>
>>
>>  Thanks for the information to have a better decision.
>>
>>  I am Nomcom-eligible and you can add me to the signature list.
>>
>>
>>/Arturo Servin
>>
>>
>>On 04/11/2012 12:15, Bert Wijnen (IETF) wrote:
>>> Thanks for extra info.
>>> 
>>> You can add me to the list who sign the request for recall.
>>> 
>>> Bert
>>> 
>>>> --On Saturday, 03 November, 2012 11:36 -0400 Russ Housley
>>>>  wrote:
>>>>
>>>>> John:
>>>>>
>>>>>>> I assume at this point the IAOC would like to pursue the
>>>>>>> recall option?  If not, please be very clear about it to the
>>>>>>> list as I haven't actually seen a request from the IAOC for
>>>>>>> that process to proceed as far as I can tell.
>>>>>>
>>>>>> Because I am personally very reluctant to see this handled by
>>>>>> recall, I want to ask a slightly different question:  Are the
>>>>>> people who met with Marshall convinced that he understood
>>>>>> that, if he did not resign, a recall was almost certain to be
>>>>>> initiated as our next step.  If the answer is "yes", he's made
>>>>>> his choice and I am ok with signing the petition.   If not, it
>>>>>> is possible that more discussion would be in order after the
>>>>>> petition process is complete.
>>>>>>
>>>>>> I hope that, when Lynn accepts the petitions, another effort
>>>>>> (or several) will be made to et Marshall's attention -- it
>>>>>> presumably is not too late for him to resign until after the
>>>>>> relevant committee is appointed.
>>>>>
>>>>> At the end of our visit, I believe that Marshall understood
>>>>> that there were three possibilities:
>>>>>
>>>>> 1) Tell the community that he intends to resume participation;
>>>>> 2) Resign;
>>>>> 3) Do nothing, which would very likely result in a recall.
>>>>>
>>>>> Russ
>>>>
>>>>
>>>>
>>>>
>>>>
>

Re: Recall petition for Mr. Marshall Eubanks

[Livingood, Jason]

Same here. I'm noncom-eligible and suppose the recall.


Jason Livingood

On 11/4/12 11:45 AM, "Arturo Servin"  wrote:

>
>   Thanks for the information to have a better decision.
>
>   I am Nomcom-eligible and you can add me to the signature list.
>
>
>/Arturo Servin
>
>
>On 04/11/2012 12:15, Bert Wijnen (IETF) wrote:
>> Thanks for extra info.
>> 
>> You can add me to the list who sign the request for recall.
>> 
>> Bert
>> 
>>> --On Saturday, 03 November, 2012 11:36 -0400 Russ Housley
>>>  wrote:
>>>
 John:

>> I assume at this point the IAOC would like to pursue the
>> recall option?  If not, please be very clear about it to the
>> list as I haven't actually seen a request from the IAOC for
>> that process to proceed as far as I can tell.
>
> Because I am personally very reluctant to see this handled by
> recall, I want to ask a slightly different question:  Are the
> people who met with Marshall convinced that he understood
> that, if he did not resign, a recall was almost certain to be
> initiated as our next step.  If the answer is "yes", he's made
> his choice and I am ok with signing the petition.   If not, it
> is possible that more discussion would be in order after the
> petition process is complete.
>
> I hope that, when Lynn accepts the petitions, another effort
> (or several) will be made to et Marshall's attention -- it
> presumably is not too late for him to resign until after the
> relevant committee is appointed.

 At the end of our visit, I believe that Marshall understood
 that there were three possibilities:

 1) Tell the community that he intends to resume participation;
 2) Resign;
 3) Do nothing, which would very likely result in a recall.

 Russ
>>>
>>>
>>>
>>>
>>>

Re: So, where to repeat? (was: Re: management granularity)

[Livingood, Jason]

BTW, if anyone finds the venue question extremely compelling / interesting
-- consider seeking a spot on the IAOC during the next nominating period.

- Jason

Re: management granularity (Re: Meeting "lounges" at IETF meetings)

[Livingood, Jason]

On 8/4/12 1:31 PM, "Dave Crocker"  wrote:

>However the tendency of the community has been to express preference for
>the tourism of going to new places.
>
>If we really want venues to function towards some ideal, we need the
>benefit of a multi-visit learning curve.
>
>And it means we stop being tourists.

Of course holding meetings in a range of locations, some new, also
provides the opportunity to attract new meeting hosts rather than relying
on a small pool of regular hosts. Ultimately, there are pros and cons to
either model and the current model does not seem especially bad (quite the
contrary I think).

And, as they say, 'variety is the spice of life'. ;-)

Perhaps when we the Internet is less dynamic (I hope it is never so) we
could meet in just one city all the time, as I understand some other
standards development group does. ;-)

Jason

2012 ISOC Board of Trustees Election Results (IETF List)

[Livingood, Jason]

On behalf of the Internet Society¹s Election Committee, I wish to extend
our appreciation and thanks to all of the nominees and final candidates
for the Board of Trustees. We are quite honoured to have such
well-qualified people so interested in serving the Internet Society!

The election results were certified on 24 May 2012 and the challenge
period concluded 10 June 2012. The process ran smoothly and the Election
Committee does not have any issues or concerns to report. The new Trustees
will be seated at the Internet Society Board Meeting in Vancouver, Canada,
on 4 August 2012.

CHAPTERS
In the Chapter membership election, we had three candidates:
1. Gihan Dias
2. Sala Tamanikaiwaimaro
3. Rudi Vansnick

55 out of the 86 Chapters voted, which is a vote participation rate of
63.95%. In the previous election, the vote participation was 79.49%.

Rudy Vansnick received the highest number of the votes and has been
elected for a three-year term.

ORGANISATIONS
In the Organisation membership election, we had six candidates:
1. Keith Davidson
2. Marshall Eubanks
3. David Farber
4. Demi Getschko
5. Byron Holland
6. Bevil Wooding

52 of the 109 Organisation Members, or 47.71%, voted. They had the
opportunity to vote for up to two candidates, with votes weighted by the
class of membership. In the previous election the vote participation was
50.47%, on a group size of 107 organizations.

Keith Davidson and David Farber, receiving the largest weighted vote
counts, have been elected for three-year terms.

INTERNET ENGINEERING TASK FORCE (IETF)
Using the process documented in RFC 3677, the IAB has re-appointed Eric
Burger as the IETF appointee to the ISOC Board.

We congratulate all of the new and returning trustees and look forward to
working with them soon on the Board of Trustees. We also thank all
nominees and final candidates for their participation, as well as ISOC
staff for their support of this critical process.

Respectfully submitted,

Jason Livingood, Chair
Alain Aina and Theresa Swinehart, Election Committee Members

Re: Last Call: (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC

[Livingood, Jason]

On 5/10/12 2:30 AM, "SM"  wrote:

>There are times when it is difficult to keep assuming that people are
>acting in a responsible fashion given the high levels of
>unpleasantness.  The situation can be such that simple gentle paths
>are ignored.

This is IMO perhaps more a reflection of the bizarre state of patent laws
for software, processes, and methods around the world than the collective
maliciousness of IETF participants.

We may surely have some people with bad intentions but I think by and
large it's more 'we're engineers and it's hard to figure out all this
patent stuff' -- especially when the law keeps changing. Were it easy, the
discussion/update a few years ago if IETF IPR policy would have taken only
a week or two. 

I see the risks here including that this is the start of masses of lawyers
showing up at every IETF, etc. That'd kinda be a bummer (no offense to
lawyers). 

Jason

Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC

[Livingood, Jason]

On 2/21/12 2:54 AM, "Lorenzo Colitti" 
mailto:lore...@google.com>> wrote:
I think the suggested change does not go far enough. The "high-service-level 
domains" that prompted this draft to be written, and all the implementers I'm 
currently aware of, are decommissioning the practice.

So the paragraph that states, "It is unclear how implementers will judge when 
the network conditions will have changed sufficiently to justify turning off 
DNS Resolver Whitelisting and/or what the process and timing will be for 
discontinuing this practice" is still incorrect. Can you just remove the 
paragraph and start the section with "Many implementers have announced that 
they plan to permanently turn off whitelisting beginning on..." ?

I've changed it around to the following:

Domains that choose to implement DNS Resolver Whitelisting generally consider 
it to be a temporary measure. Many implementers have announced that they plan 
to permanently turn off DNS Resolver Whitelisting beginning on the date of the 
World IPv6 Launch, on June 6, 2012 . For any 
implementers that do not turn off DNS Resolver Whitelisting at that time, it 
may be unclear how each and every one will judge when the network conditions to 
have changed sufficiently to justify turning off DNS Resolver Whitelisting. 
That being said, it is clear that the extent of IPv6 deployment to end users in 
networks, the state of IPv6-related impairment, and the maturity of IPv6 
operations are all important factors. Any such implementers may wish to take 
into consideration that, as a practical matter, it will be impossible to get to 
a point where there are no longer any IPv6-related impairments; some reasonably 
small number of hosts will inevitably be left behind as end users elect not to 
upgrade them or as some hosts are incapable of being upgraded.


Thanks for your input,
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC

[Livingood, Jason]

To be more specific, at least section 5.5 ("it is unclear how implementers will 
judge when the network conditions will have changed sufficiently to justify 
turning off DNS Resolver Whitelisting and/or what the process and timing will 
be for discontinuing this practice") is now incorrect. It *is* clear, and it's 
what those implementers are doing as part of World IPv6 Launch.

Does that make more sense?

As the author, if it helps I plan to make the following change to Section 5.5 
following the conclusion of IETF Last Call. I ran this by a few folks already 
and it seems broadly acceptable (have not heard from Lorenzo yet though).

Jason

CURRENT 5.5:
5.5.  Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consider 
it to be a temporary measure. It is unclear how implementers will judge when 
the network conditions will have changed sufficiently to justify turning off 
DNS Resolver Whitelisting and/or what the process and timing will be for 
discontinuing this practice, though the extent of IPv6 deployment to end users 
in networks, the state of IPv6-related impairment, and the maturity of IPv6 
operations are all clearly factors. However, implementers may wish to take into 
consideration that, as a practical matter, it will be impossible to get to a 
point where there are no longer any IPv6-related impairments; some reasonably 
small number of hosts will inevitably be left behind as end users elect not to 
upgrade them or as some hosts are incapable of being upgraded.

PROPOSED 5.5 (NEW TEXT IN ALL CAPS):
5.5.  Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consider 
it to be a temporary measure. It is unclear how implementers will judge when 
the network conditions will have changed sufficiently to justify turning off 
DNS Resolver Whitelisting and/or what the process and timing will be for 
discontinuing this practice, though the extent of IPv6 deployment to end users 
in networks, the state of IPv6-related impairment, and the maturity of IPv6 
operations are all clearly factors. However, SOME IMPLEMENTERS HAVE ANNOUNCED 
THAT THEY PLAN TO PERMANENTLY TURN OFF WHITELISTING BEGINNING ON WORLD IPV6 DAY 
IN JUNE 2012 [REFERENCE]. IN ANY CASE, implementers may wish to take into 
consideration that, as a practical matter, it will be impossible to get to a 
point where there are no longer any IPv6-related impairments; some reasonably 
small number of hosts will inevitably be left behind as end users elect not to 
upgrade them or as some hosts are incapable of being upgraded.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Hyatt Taipei cancellation policy?

[Livingood, Jason]

On 8/23/11 3:09 PM, "Fred Baker"  wrote:

>I wouldn't discount the effect of the value of the dollar on hotel rates
>as measured in US dollars.

I suspect Fred is spot on -- current exchange rate fluctuation is
undoubtedly a huge issue. I would speculate that most hotels would
negotiate for payment in their local currency and that since the time of
that agreement the US dollar has depreciated against most currencies
(blame 'quantitative easing' I suppose).

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*

[Livingood, Jason]

Dave - Thanks for the additional feedback. Any changes noted below will be made 
soon in a -06 update. See inline comments.

Regards
Jason

On 5/30/11 11:34 AM, "Dave CROCKER" 
mailto:d...@dcrocker.net>> wrote:

(I see that you've posted -05.  This response is for completeness.)

On 5/29/2011 7:54 PM, Livingood, Jason wrote:
[JL] Duly noted in my previous emails. I'm keeping the naming as an open issue
in the –04 and will be seeking WG and WG co-chair guidance one way or the other.

One of the reasons for cross-area review is to look for cross-area problems.

Separate from the legal formalities, the purpose of 'trademark' is to try to
avoid market confusion.  Market confusion was exactly the reason that I raised
concern about the naming and I wasn't the only one who noticed the problem.  (My
original, informal posting was directly result of that confusion...)

So I'm sorry to see that the naming conflict is felt to be irrelevant by those
running the working group.  (I was also a little surprised to see that that core
of folk constitute working group rough consensus, for removing open items.)

As for the actual term "whitelisting" I suppose we should admire the boldness of
the view that access to v6 is a priviledge -- note that that's the denotational
perspective of the word whitelisting...

[JL] Duly noted.

 operator of a website, such as www.example.com, the operator
 essentially applies an access control list (ACL) on the authoritative
 DNS servers for the domain example.com. The ACL is populated with

 An ACL usually is a yes/no mechanism. Here, however, the mechanism is for
 asserting a preference for IPv6 over IPv4.

 That does not seem to match the definition of ACL that I'm used to, unless 
the
 semantic is defined as denying IPv4 access to the listed clients.

 The term ACL is particularly odd to use if the mechanism pertains to 
responses
 rather than queries.


[JL] I am using 'ACL' in the most general possible sense and am open to
alternative descriptors if you wish to suggest one. But most people seem to know
an ACL is a list that, if you are listed on it, grants you access to some
resource. In this case if the resolver is on the list then it gets  RRs.

On reflection, the term is growing on me for this use.

" ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good
labels.  They provide useful, direct and precise meaning, while avoiding the
various referential and denotational problems of a loaded term like whitelist.

[JL] Great! And I like thinking about it more in terms of granting "access" to 
 RRs than viewing it as "blocking"  RRs, as I find access control a 
more neutral term and one that is still easy to understand conceptually.

[JL] I took a stab at a new diagram in –04 — so take a look and let me know if
it is what you are suggesting (I've left the original one in for now).

Took a quick look at the added diagram in the new draft.  The thing about a
protocol timeline diagram is that it uses verticality to provide ordering.  So a
response is lower down than a request. I don't get that from your Figure 2.

[JL] Oh! Now I understand what you were asking for. See my email under separate 
cover with an example to see if I am getting closer. Others can see what I now 
have in draft form at 
https://img.skitch.com/20110531-j1r2ubr43273fd9i8xuj6btyn9.jpg


(By the way, your first sub-scenario, with Resolver 1, shows only a v4 response,
without indicating whether the resolver sent a v6 or v4 query.  For the review,
I think this distinction between transport and data -- "how is the
query/response transported" vs. "what RRs are returned" -- was a continuing
point of confusion for me. )

[JL] Ack. I'll add an extra note at the top of the diagram to clarify that the 
access control logic is independent of whether IPv6 transport is used between 
the host and resolver, or resolver and authority.

 At least one highly-trafficked domain has noted that they have
 received requests to not send DNS responses with  resource
 records to particular resolvers. In this case, the operators of


 "At least one" seems a rather tiny statistic. Perhaps the actual statistic 
is
 significantly larger?


[JL] It does not seem to be. Other than this being passed along by Google, I've
not heard of any similar stories. Nevertheless, it seemed interesting enough to
include.

As an anecdote, it is perhaps interesting.  As a basis for promoting the entire
effort, not so much.  I couldn't tell which role it was serving, but it felt
like the latter.


 network infrastructure is not yet ready to handle the large traffic
 volume which may be associated with the hosts in their network
 connecting to the websites

Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*

[Livingood, Jason]

On 5/31/11 12:00 PM, "Tony Finch" mailto:d...@dotat.at>> wrote:

Speaking of confusing, the first sentence of the abstract and introduction
in the current revision of the draft is an abomination that should be
taken out and shot.

[JL] Great feedback – I just did it. Here's the updated Abstract (carried into 
the Intro as well). If you think it is still convoluted, just say so and I'll 
take another turn at it.

New text:
"This document describes the practice and implications of whitelisting DNS 
recursive resolvers in order to limit  resource record responses (which 
contain IPv6 addresses) sent by authoritative DNS servers. This is an IPv6 
transition mechanism used by domains as a method for incrementally 
transitioning inbound traffic to a domain from IPv4 to IPv6 transport. The 
audience for this document is the Internet community generally, particularly 
IPv6 implementers."

Thanks!
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*

[Livingood, Jason]

On 5/31/11 2:48 AM, "Lorenzo Colitti" 
mailto:lore...@google.com>> wrote:

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli 
mailto:joe...@bogus.com>> wrote:
But you've contributed to this document, so have others from that list.

I don't want to contribute to the document

While you have not contributed text per se (by sending it directly), I try to 
be a good listener and items you and other Googlers have raised have been 
included in the document around motivations and so on. Even new Sections 3.2 
and 3.2 were added based on listening to you and/or your colleagues talk about 
the issue (and some direct conversations a couple of weeks ago).

In any case, I appreciate your feedback and opinions. At the end of the day it 
is only an informational I-D, and not a standard or BCP, so maybe not such a 
big deal.

Regards
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

Hi – Thanks for the feedback and see a few selected responses inline below. A 
–04 update is coming soon.

Thanks
JL

On 5/3/11 4:43 AM, "SM" mailto:s...@resistor.net>> wrote:

Hi Jason,
At 11:48 02-05-2011, Livingood, Jason wrote:
In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS  Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to act on. ;-)
If there are recommendations on alternatives, I'm all ears.

Repurposing a sentence from the
draft-ietf-v6ops-v6--whitelisting-implications-03:

   "By engaging in a DNS tradeoff, they are attempting to
shield users with impaired access from the symptoms of those
impairments."

Web content providers use a DNS tradeoff to avoid losing quality and
money as most ISPs are reluctant to pour money into IPv6.  At least
Comcast has a plan to provide each of their users with
18,446,744,073,709,551,616 IPv6 addresses.

[JL] What has become more apparent since the –03 draft is that it is not just 
about the impairment level. Even (or perhaps especially) if every ISP was 100% 
dual stack, some large domains would still want or need a mechanism to 
incrementally control the addition of IPv6 traffic to their domain. I have 
tried to add some new text to the –04 update to better explain this on behalf 
of implementers or potential implementers.

Given that draft-ietf-v6ops-v6--whitelisting-implications has
been reviewed by DNSOP and v6ops, and that the intended status is
Informational, it is difficult to give it a "DNP".  RFC 3901 mentions
"Policy Based Avoidance of Name Space Fragmentation".  The DNS
technique used in the draft (split-view) contributes to name space
fragmentation.

If you wanted to argue for "DNP", you could have the following text
from the v6ops Charter at the bottom of the list:

  "IPv6 operational and deployment issues with specific protocols or
   technologies (such as Applications, Transport Protocols, Routing
   Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
   the groups or areas responsible for those protocols or technologies.
   However, the v6ops WG may provide input to those areas/groups, as
   needed, and cooperate with those areas/groups in reviewing solutions
   to IPv6 operational and deployment problems."

If you want to argue against "DNP", you can always say that you are
merely documenting the stupid things people have to do get IPv6 deployed.

I am stupid but I am not that stupid to go and argue about a draft
that has been blessed by DNSOP and v6ops.  :-)  Andrew Sullivan
mentioned WCP [1].  That RFC sub-series does not exist yet.  The best
fit is FYI.

[JL] Yup.

As a comment that will not be considered as part of the Last Call, I
would have given the draft a DNP if I had to review it.  I don't have
to say that as the draft already got a five DISCUSS rating.  That
won't prevent a well-known search engine from deploying the mechanism
described in this draft.  Someone might come to me and say that
"well-known search does this, why can't you do it; it's even a
RFC".  I'll read the Mathematical Principles of Natural Philosophy to
see whether I can find an answer to that. :-)

[JL] I came at this from the perspective of someone who had a bad experience 
with whitelisting and was extremely concerned by all of the implications if it 
became a long-standing practice (see an early document here, 
http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf). As a WG 
document the consensus was to make sure that the motivations were documented, 
as well as the potential implications.  In my personal opinion, I can 
understand why some domains may choose to adopt the practice and I may do the 
same in their situation. At the same time, I hope as few domains as possible do 
this and that it is as short-lived as possible. Then again, if the Internet 
crashes and burns on World IPv6 Day, then who knows what will happen.

On an unrelated note, there was a mistake in the message I posted
previously [2].  The last sentence should be read as:

  As I do not meet the religious requirements, I cannot take a
position on this draft.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg66311.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg66203.html


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

Hi John - Thanks for the detailed review. I'm planning a -04 update soon, FWIW.

Specific responses inline below.

Thx,
Jason


On 5/2/11 7:44 PM, "John Leslie" mailto:j...@jlc.net>> wrote:

Livingood, Jason 
mailto:jason_living...@cable.comcast.com>> 
wrote:
To: John Leslie mailto:j...@jlc.net>>...
As I read it, this says that certain DNS servers will be configured
to _not_ return  records to  queries by default.
This strikes me as a really-strange transition mechanism.
Depends on a number of factors for a content provider.

   Actually, no -- none of these factors make me feel it's any less than
_REALLY_ strange.

The more traffic a domain receives the more likely they are to consider
this practice as a transition mechanism from what I have observed.

   "Transition mechanism" is really-close to an oxymoron.

This practice can give a large domain some level of control in turning
on IPv6 access to their content, whereas they would lack this since
they would turn it on for everyone when publishing the  RR in the
DNS.

   It doesn't give nearly as much control as they seem to think it does.
This blocks  records, not based on the host interested in using them,
but based on some feature (IP address?) of the intermediate DNS resolver.

[JL] Quite so, and many in the WG feel it is difficult to use the resolver as a 
proxy for end use host IPv6-related impairment. Nevertheless, implementers feel 
it is good enough and the best available mechanism, and works reliably enough 
for their (temporary) use.

It's traditional to configure hosts to use two (or more) DNS resolvers
to mimimize the delays and disruptions.

   It will be very common for an end-host to alternate -requests
between one resolver which happens to be -blocked and another which
happens to be "whitelisted". I cringe in fear of taking the support
calls from such customers.

[JL] You and me both!!  ;-)

Once a comfort level and operational stability is achieved I would
expect most domains to move away from the practice, but that is TBD.

   I would expect a painful number of domains to forget it's there. :^(

[JL] Fair enough – which is why the 'risk of operational momentum' has been 
noted in the I-D. I don't know if it'll happen with this practice, but it would 
not be the first time that a temporary mechanism becomes a foundational one.

Certainly what happens on World IPv6 Day will bear on this question
in important ways (when  RRs are published without the use of
DNS whitelisting).

   I predict a majority will turn off  records for their regular
www.example.com on WorldIPv6Day+1.

[JL] To some extent this is expected — everyone will want to do some data 
analysis afterwards before they make a decision on what to do next. But 
certainly Heise Online (as cited in the I-D) and others feel the risk was low 
enough on their domains to go ahead and publish a  RR. Every domain will be 
different and make the decision on their own.

   But that's OK: there are other ways to make progress.

   And the pressure should probably be applied to browser-software writers,
so that when an end-user finds himself IPv6-impaired, he can simply shift
to a different browser,

Color me thoroghly confused.
Hopefully that's more over the practice than the document;

   Indeed, I _am_ more confused by the practice than the document.

   But the document is confusing enough! What does it encourage me to
_do_?

[JL] Suggest I simplify the document, I'm sure. ;-) I've made some effort to do 
this for the –04 version based on all the feedback on –03. I'm also planning a 
top-to-bottom simplification after the –04.  So, point well-taken.:-)


if you wish to see improvements in the I-D just say so.

   Personally, I wish you'd do a nearly-global

s/DNS whitelisting/-blocking/

   It's a much more descriptive term.

[JL] The naming of the practice is noted as an Open Item in the draft, so I'll 
be discussing that with the WG chairs.

   Also, I'd appreciate less of "this solve a transition problem" and
more of "this doesn't even do what the folks seem to think it does".

   It's arguably reasonable to -block to DNS resolvers whose
managers ask for it; but it's not at all reasonable to -block by
default. IMHO, it would be better to tell folks that ask you to
-block to switch to resolver software that can -block to
certain end-users. After all, the problem _isn't_ localized on the
DNS resolver.

   And the document does nothing to help me figure out what to do to
enable a venturesome customer to _use_ IPv6 to a site that turns on
this -blocking!

   :^( :^(

[JL] All good feedback – thanks!

Jason




--
John Leslie mailto:j...@jlc.net>>

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

Thank you for your thorough review, Dave. Changes will be made in an upcoming 
–04 revision. Some more specific comments can be found inline below.

Thanks!
JL

PS – I have at least one other email from you in my queue for this I-D – I've 
not forgotten about it. :-)

On 4/29/11 7:32 PM, "Dave CROCKER" 
mailto:d...@dcrocker.net>> wrote:


Review:

Title:  IPv6  DNS Whitelisting Implications
I-D:draft-ietf-v6ops-v6--whitelisting-implications-03

By: D. Crocker mailto:dcroc...@bbiw.net>>
Date:   29 April 2011


Summary:

This draft is a discussion of a technique for resolving a dual-stack problem
between IPv4 and IPv6, through the use of special DNS records.

The document appears to continue a recent use of the term 'whitelisting' that
strongly conflicts with long-standing use of the term by the anti-abuse 
community.

The document needs to do a more careful job of introducing the problem it is
solving and the explaining the way the 'whitelisting' mechanism works.

I also very strongly encourage finding a different term.

[JL] There's been a great deal of discussion on the mailing list about this. 
While it appears the consensus is to leave it as-is, your point is well noted 
and I have listed this in the Open Items list of the –04 draft and will be 
consulting with the WG chairs for direction on the matter.


d/


Abstract

The objective of this document is to describe what the whitelisting
of DNS  resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean
something else?

[JL] You are quite correct. Another reviewer also noted my error in this 
sentence and it is corrected in the –04 version.

Comcast's own considerable expertise notwithstanding, has this doc been vetted
with a range of organizations that actually DO whitelisting?

[JL] Folks from organizations that perform or are considering IPv6 DNS 
whitelisting have provided feedback on the draft, which has been incorporated 
into previous versions. Additional feedback has been shared which will be in 
the –04 revision.

Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops folks
whose names I know.  (But then, I only know a few...)

[JL] It has not specifically been sent to groups like MAAWG, as I think this 
form of DNS server-related whitelisting is different from mail server 
whitelisting. I can certainly do so, but I'm not sure those groups will be 
interested as it is not particularly anti-abuse related.

whitelisting, as well as the implications of this emerging practice
and what alternatives may exist.  The audience for this document is
the Internet community generally, including the IETF and IPv6
implementers.

I suspect that product marketers won't have much interest in this.  I suspect
that the target for this is anti-abuse technical and operations staff.

[JL] You are doing a good job illustrating the confusion over the use of the 
term 'whitelisting'. ;-) The target is actually not A/A tech and ops personnel, 
since the draft is specifically related to the IPv6 transition and not A/A or 
even messaging.



1.  Introduction

This document describes the emerging practice of whitelisting of DNS
 resource records (RRs), which contain IPv6 addresses, hereafter
referred to as DNS whitelisting.  The document explores the
implications of this emerging practice are and what alternatives may
exist.

The practice of DNS whitelisting appears to have first been used by
major web content sites (sometimes described herein as "highly-

Really?  Not for email first?

[JL] You now get a +2 for further illustrating the potential for confusion over 
the terms. ;-) But I'm referring specifically to this (which is how the updated 
–04 text reads):
"whitelisting of DNS recursive resolvers in order to limit  resource 
records responses"

trafficked domains" or "major domains").  These web site operators,
or domain operators, observed that when they added  resource
records to their authoritative DNS servers in order to support IPv6

Oh.  You mean /IPv6/ whitelisting.

access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both  and A
resource records.  The fraction of users with such impaired access
has been estimated to be roughly 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
Brokenness].  Thus, in an example Internet Service Provider (ISP)
network of 10 million users, approximately 7,800 of those users may
experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is in 

Re: [v6ops] Review of draft-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

In the case at hand, the list does not contain  RRs as the abstract
suggests, it contains IPv6-capable resolvers. The whitelist isn't
published in the DNS, so it doesn't match the existing use of the phrase
"DNS whitelist".

[JL] Oops! Thanks for noticing this – I have corrected it in the Abstract and 
Introduction (in my upcoming –04 update).

Thanks for catching this,
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC

[Livingood, Jason]

Thank you for your review, and a –04 revision is coming soon. Other comments 
inline below.

Thanks!
Jason


On 4/26/11 5:51 AM, "Pekka Savola" 
mailto:pek...@netcore.fi>> wrote:

On Fri, 15 Apr 2011, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6  DNS Whitelisting Implications'
   as an
Informational RFC

This is an ops-dir review of
draft-ietf-v6ops-v6--whitelisting-implications-03.

The document is readable and could be published as-is.  I share some of the
concerns already expressed in the document, but I think the doc strikes a
reasonable balance between the concerns and practical points.

One bigger comment:
---

Section 6 on deployment scenarios seems too black and white: either it is
done ad-hoc or (completely) universally.  The latter is unfeasible.

[JL] I received similar feedback from others and have tried to address this 
better in the upcoming –04 version.

The document should cover a middle ground which is already discussed in
[NW-Article-DNS-WL], i.e., one or more whitelisting information providers
would be used by multiple content networks.  This has many benefits compared
to completely ad-hoc model, and is feasible compared to universal model.

[JL] Added a note concerning this in the I-D.


The "universal deployment model" proposition has created ripples throughout
the document (one such place is S 7.3.7), and I think the document might
have been clearer if that was taken out completely -- or at least, issues
related to each deployment model would be more clearly separated.

[JL] Good question, which is such a meta-concern that I'm going to list it in 
the open items tracker at the end of the document for consideration after the 
–04 update (since so many other changes are taking place in that version).

8.3.1. Solving Current End User IPv6 Impairments
...
One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such
an effort.  Of course, since just such a community effort is now
underway for IPv6, it is possible that this would call for only a
moderate amount of additional work.

... I would observe that ad-hoc whitelisting is already requiring a lot of
work from each of whitelisting providers.  Would this require more than
that?  If the alternative is to do nothing (no whitelisting, no user
impairment notification) that is clear the winner from the selfish POV. But
if the choice is between whitelisting and alerting, I don't see much
difference between the two.  Both could benefit from joint activities, but
both can also be operated in an ad-hoc fashion.


editorial:
--

7.3.7. Additional Implications If Deployed On An Ad Hoc Basis

Additional implications, should this be deployed on an ad hoc basis,
could include scalability problems relating to operational processes,
monitoring, and ACL updates.

... this could be read to imply that S 7.3.1-6 would be applicable to
universal deployment.  This is not what is meant.  Maybe clarify somewhat
like as follows:

Previous subsections described implications that apply to both ad-hoc and
universal deployment models.  Some additional implications are specific
to ad-hoc deployment models, namely ...

[JL] Great suggestion! I have made this change.


S 7.5

governmental, and/or cultural conflicts, given the new control point
which has be established with DNS whitelisting.  For example, in one

s/be/been/

[JL] Corrected


[IPv6 Brokenness]
   Anderson, T., "Measuring and Combating IPv6 Brokenness",
   Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
   .


s/2011/2010/

[JL] Corrected

Thanks again,
Jason



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC

[Livingood, Jason]

Hi Bernard – I've finally found the time to close out the last bits of feedback 
in this version of the draft. Your comments will be incorporated shortly into a 
–04 version of the document. Please see specific replies inline below.

Thanks!
Jason


On 4/18/11 2:08 PM, "Bernard Aboba" 
mailto:bernard_ab...@hotmail.com>> wrote:

Overall, I think this is a useful document.

My suggestions below mostly relate to potential organizational improvements, as 
well as as a bit more detail in some areas.

Section 2

This section talks about how white-listing works, but does not talk about 
potential mechanisms by which the whitelist is determined.  For example, in 
addition to techniques for manually maintaining the whitelist, there have been 
some suggestions that would involve automatic determinations (e.g. only 
answering with  RRs if the query comes in over IPv6).   It might be useful 
to cover some of the proposals, since they might have different implications.

[JL] I added a bit of text in the ad hoc DNS whitelisting section noting that 
there are two approaches. I did not include the part about only responding with 
a  RR if the query comes in via IPv6, as I've not heard much about this in 
practice and discussion from implementers seems to indicate that even if they 
recursive server sent the query over IPv6 they still may have end hosts that 
are broken.

Section 2.1

Is the term "IP address" here intended to include both IPv4 and IPv6 addresses?

[JL] Yes, and I updated the text to clarify that.

Section 3


   At least one highly-trafficked domain has noted that they have
   received requests to not send DNS responses with  resource
   records to particular resolvers.  In this case, the operators of
   those recursive resolvers have expressed a concern that their IPv6
   network infrastructure is not yet ready to handle the large traffic
   volume which may be associated with the hosts in their network
   connecting to the websites of these domains.  This concern is clearly
   a temporary consideration relating to the deployment of IPv6 network
   infrastructure on the part of networks with end user hosts, rather
   than a long-term concern.  These end user networks may also have
   other tools at their disposal in order to address this concern,
   including applying rules to network equipment such as routers and
   firewalls (this will necessarily vary by the type of network, as well
   as the technologies used and the design of a given network), as well
   as configuration of their recursive resolvers (though modifying or
   suppressing  resource records in a DNSSEC-signed domain on a
   Security-Aware Resolver will be problematic Section 10.1).

[BA]  This paragraph seems to be distinguishing "blacklisting" from 
"whitelisting" as well as describing some of the implications of attempting to 
suppress  RRs in the recursive resolver.  It might be worthwhile to 
introduce the distinction between "blacklisting" and "whitelisting" earlier on.
Such a section might also include the following paragraph from Section 7.3.7:

[JL] Good idea – I added a brief section contrasting whitelisting and 
blacklisting, including some of the text you suggest.

   It is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, and whether or how this could feasibly
   be coordinated across the Internet, which may be proposed or
   implemented on an ad hoc basis when a majority of networks (or
   allocated IPv6 address blocks) have been whitelisted.  Finally, some
   parties implementing DNS whitelisting consider this to be a temporary
   measure.  As such, it is not clear how these parties will judge the
   network conditions to have changed sufficiently to justify disabling
   DNS whitelisting and/or what the process and timing will be in order
   to discontinue this practice.

Section 4


   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS whitelisting, it is
   not clear if the level of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be that websites are only
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are simply unable to or are
   otherwise not in a position to be able to measure IPv4 impairment
   (since this could result in no Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and that such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet for a variety of reasons.  Of course, this comparison of the
   level of worldwide IPv6 impairments to IPv4 impairme

Re: TSVDIR review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications

[Livingood, Jason]

Hi Joe – Thank you for your thorough review and detailed response. Your 
feedback will be incorporated into a –04 update with other changes received in 
last call and from the IESG. (I'm still working through all of the changes 
though.)

In any case, see my detailed responses inline below. I appreciate any suggested 
changes to the proposed new text of course.

Regards
Jason

On 4/28/11 4:38 PM, "Joe Touch" mailto:to...@isi.edu>> wrote:

Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this 
review.

The document describes the issues associated with the practice of
whitelisting in DNS servers, in an attempt to limit which recursive
resolvers receive responses to requests for  (IPv6) records.

The practice of whitelisting can have significant impact on transport
protocols in the reachability of IPv6 endpoints. There are no transport
issues of a more specific nature discussed or determined as part of this
review.

I do have some other concerns which are noted below, and which are
offered for consideration.

I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.

Joe

-

Overall, this document is quite long and has many gratuitous digressions
which could easily be omitted. It is unnecessarily verbose and lengthy
for its topic. E.g., the architectural implications that stretch this
issue into network heterogeneity are a bit of a stretch, and the
discussion (and citation) for Newton's notion of momentum is unnecessary.

[JL] Thanks for the general feedback. As for the inclusion of CPE homogeneity 
being encouraged (Section 7.4) as a result of whitelisting, I am attempting to 
highlight that on the one hand there is a natural trend towards greater 
heterogeneity while whitelisting policies may encourage an opposite trend back 
towards homogeneity. In part this is due to the fact that so may different 
types of CPE exist and these vary widely with respect to IPv6-related 
impairments and capabilities. But it seems that whitelisting approvals for 
domains may occur more readily for those networks with a greater level of 
control (or complete control) over endpoints, where less variation in those 
devices exists as a result of that control, since the network can then push out 
device fixes for IPv6 impairments and so on. This is a tension that I know I as 
an ISP feel – on the one hand it seems desirable to have greater control over 
and less variation of CPE in order to win approval to be added to whitelists, 
while on the other hand there is a great deal of pressure in the opposite 
direction to enable any IP-capable CPE to connect (often this is encompassed in 
various countries' "open Internet" or "network neutrality" guidelines).

Blacklisting is noted in other environments in Sec 6, and noted as an
alternative for the DNS  issue in a cursory fashion in Sec 7.3.7. It
should certainly be introduced and defined earlier, and included in the
alternatives discussed in Sec 8. Blacklisting provides a useful
alternative because it requires explicit action to inhibit, rather than
requiring explicit action to avoid, and the tradeoff between
blacklisting and whitelisting should be discussed in more detail.

[JL] This is an excellent suggestion. I have acted on it in the following ways:
1 – Added this to Section 2, How DNS Whitelisting Works:
"At a high level, using a whitelist means no traffic is permitted to the 
destination host unless the originating host's IP address is contained in the 
whitelist. In contrast, using a blacklist means that all traffic is permitted 
to the destination host unless the originating host's IP address is contained 
in the blacklist."

2 – I have added a new section in the solutions/alternatives, 8.4 Implement DNS 
Blacklisting, with the following text:
"Some domains may wish to be more permissive than if they adopted DNS 
whitelisting [Section 8.2], but not still have some level of control over 
returning  record responses [Section 8.3]. An alternative in this case may 
be to employ DNS blacklisting, which would enable all DNS recursive resolvers 
to receive  record responses except for the relatively small number that 
are listed in the blacklist. This could enable an implementer to only prevent 
such responses where there has been a relatively high level of IPv6-related 
impairments, until such time as these impairments can be fixed or otherwise 
meaningfully reduced to an acceptable level.

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

>Perhaps the document could include the arguments for and against this
>practice?  That way, someone who is new to IPv6
>deployment theory can quickly get up to speed.
>
>I'm very much in favor of documents which say "don't do this -- but if
>you have to, here's how."  But they have to include enough context for
>someone to understand why it'd be better if they didn't.

In the last update I added Section 9 "Is DNS Whitelisting a Recommended
Practice?"to attempt to address the question of "should a domain do this
or not?" (see 
http://tools.ietf.org/html/draft-ietf-v6ops-v6--whitelisting-implicatio
ns-03#section-9).

If folks here and on v6ops think it is valuable, I could add a sub-section
to this which addresses recommended things an implementer should do
(transparent/published policies, SLA on decision making, etc.).

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

   As I read it, this says that certain DNS servers will be configured
to _not_ return  records to  queries by default.

   This strikes me as a really-strange transition mechanism.

Depends on a number of factors for a content provider. The more traffic a 
domain receives the more likely they are to consider this practice as a 
transition mechanism from what I have observed. This practice can give a large 
domain some level of control in turning on IPv6 access to their content, 
whereas they would lack this since they would turn it on for everyone when 
publishing the  RR in the DNS. Once a comfort level and operational 
stability is achieved I would expect most domains to move away from the 
practice, but that is TBD. Certainly what happens on World IPv6 Day will bear 
on this question in important ways (when  RRs are published without the use 
of DNS whitelisting).

   Color me thoroghly confused.

Hopefully that's more over the practice than the document; if you wish to see 
improvements in the I-D just say so.

Thanks
Jason


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS  Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to act on. ;-)
If there are recommendations on alternatives, I'm all ears.


Thanks
Jason




On 5/2/11 10:32 AM, "Richard L. Barnes"  wrote:

>I disagree that "whitelisting" is a reserved trademark of the anti-abuse
>community.  It's a general term for a list of things that are granted
>something.  Likewise with "blacklist" and "deny".  Which means it's
>perfectly appropriate for this document.
>
>
>
>
>
>On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote:
>
>> 
>> Review:
>> 
>> Title:  IPv6  DNS Whitelisting Implications
>> I-D:draft-ietf-v6ops-v6--whitelisting-implications-03
>> 
>> By: D. Crocker 
>> Date:   29 April 2011
>> 
>> 
>> Summary:
>> 
>> This draft is a discussion of a technique for resolving a dual-stack
>>problem between IPv4 and IPv6, through the use of special DNS records.
>> 
>> The document appears to continue a recent use of the term
>>'whitelisting' that strongly conflicts with long-standing use of the
>>term by the anti-abuse community.
>> 
>> The document needs to do a more careful job of introducing the problem
>>it is solving and the explaining the way the 'whitelisting' mechanism
>>works.
>> 
>> I also very strongly encourage finding a different term.
>> 
>> d/
>> 
>> 
>>> Abstract
>>> 
>>>   The objective of this document is to describe what the whitelisting
>>>   of DNS  resource records is, hereafter referred to as DNS
>> 
>> RRs are whitelisted?  Isn't it the addresses and not the records that
>>are whitelisted?
>> 
>> Does this mean putting whitelisting records into the DNS or does it
>>mean something else?
>> 
>> Comcast's own considerable expertise notwithstanding, has this doc been
>>vetted with a range of organizations that actually DO whitelisting?  Has
>>it been circulated through MAAWG and APWG?  Any comments from Spamhaus?
>>The Acknowledgements list does not seem to indicate a range of whitelist
>>ops folks whose names I know.  (But then, I only know a few...)
>> 
>> 
>>>   whitelisting, as well as the implications of this emerging practice
>>>   and what alternatives may exist.  The audience for this document is
>>>   the Internet community generally, including the IETF and IPv6
>>>   implementers.
>> 
>> I suspect that product marketers won't have much interest in this.  I
>>suspect that the target for this is anti-abuse technical and operations
>>staff.
>> 
>> 
>>> Status of this Memo
>>> 
>>>   This Internet-Draft is submitted in full conformance with the
>>>   provisions of BCP 78 and BCP 79.
>>> 
>>>   Internet-Drafts are working documents of the Internet Engineering
>>>   Task Force (IETF).  Note that other groups may also distribute
>>>   working documents as Internet-Drafts.  The list of current Internet-
>>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>>> 
>>>   Internet-Drafts are draft documents valid for a maximum of six months
>>>   and may be updated, replaced, or obsoleted by other documents at any
>>>   time.  It is inappropriate to use Internet-Drafts as reference
>>>   material or to cite them other than as "work in progress."
>>> 
>>>   This Internet-Draft will expire on August 26, 2011.
>>> 
>>> Copyright Notice
>>> 
>>>   Copyright (c) 2011 IETF Trust and the persons identified as the
>>>   document authors.  All rights reserved.
>>> 
>>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>>   Provisions Relating to IETF Documents
>>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>>   publication of this document.  Please review these documents
>>>   carefully, as they describe your rights and restrictions with respect
>>>   to this document.  Code Components extracted from this document must
>>>   include Simplified BSD License text as described in Section 4.e of
>>>   the Trust Legal Provisions and are provided without warranty as
>>> 
>>> 
>>> 
>>> LivingoodExpires August 26, 2011[Page
>>>1]
>>> 
>>> Internet-Draft   IPv6  DNS Whitelisting Implications   February
>>>2011
>>> 
>>> 
>>>   described in the Simplified BSD License.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> LivingoodExpires August 26, 2011[Page
>>>2]
>>> 
>>> Internet-Draft   IPv6  DNS Whitelisting Implications   February
>>>2011
>>> 
>>> 
>>> Table of Contents
>>> 
>>>   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>>>   2.  How DNS Whitelisting 

Re: World IPv6 Day and Us

[Livingood, Jason]

>Parts of the challenge here is that turning on IPv6 (publishing a )
>can also cause brokenness for users that have no IPv6 connectivity, e.g.,
>those relying on broken 6to4 relays.  This has been documented all over
>the place, for example here:
>
>
>So even if there are very few IPv6 eyeballs, this event can serve to
>flush out that flavor of brokenness.  As I understand it, part of the
>idea of everyone moving together is to get people to see the brokenness
>across multiple sites, thus to blame the network not the content
>provider, thus to pressure the networks to fix things.

Richard is exactly right on where a lot of value is. This is an
opportunity to find and fix the ~0.05% level of brokenness. Even
"non-participating" ISPs will need to take steps to prepare, and this is
of course a great forcing function within companies to ask what their IPv6
plans and to begin/continue IPv6 technical training, etc.

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: can we please postpone the ipv6 post-mortem?

[Livingood, Jason]

+1


On 10/8/10 1:02 PM, "james woodyatt"  wrote:

>everyone--
>
>IPv6 may have been born with a developmental disability, but we're not
>dealing with a corpse yet.  The patient is still alive, getting better,
>and with a bit of love and proper care, might yet grow up to make better
>and brighter music than IPv4.
>
>Maybe I'm being overly sentimental and using anthropomorphism
>inappropriately here, but really folks-- isn't it a bit unseemly to be
>arguing over how we went so "wrong" with IPv6-- and how we could do ever
>so much better the *next* time we get to reinvent the Internet if we
>avoid all the killing mistakes we made in bringing IPv6 up-- while there
>are, today, more people than ever before taking what are perceived to be
>enormous risks actually making the v4->v6 transition start to happen?
>
>
>--
>james woodyatt 
>member of technical staff, communications engineering
>
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [ietf] DNS spoofing at captive portals

[Livingood, Jason]

>>
>> c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect

draft-livingood-dns-malwareprotect concerns what is primarily an opt-in
service to block known malware sites for end users.  Hopefully that is
less controversial than the redirect one, but who knows.

draft-livingood-dns-redirect was written to do two things.  First was to
document a relatively long-standing process in a reference-able IETF
document where no documentation previously existed.  Second was to
document the best or least worst way to approach it, if a party was
planning to do so.  Since that time, I've added a bunch of stuff related
to DNSSEC to make clear an incompatibility there.  I'm a bit conflicted
though about whether to keep it as informational or consider historic.

In any case, as noted below, I'm more than happy to consider any text that
might improve these document by providing more information on opposing
viewpoints, etc.


>>   descibe these "services" in a much too friendly tone;
>>   terms like "service" and "benefits for users" are clearly
>>   abuse of language -- the above IAB statement already indicates

Sorry you feel that way.  Operators view these as services and describe
them as such, so I am simply using that language.  As I do my next pass
through the documents I will review it for any non-neutral descriptors. Of
course, also feel free to email me a list of the ones you think I should
consider revising in some manner.

>>   that similar interference with the DNS causes severe damage
>>   to user perception and performance.

The 2nd draft concerns protection from malware, which is generally assumed
to be a service that users opt-into (a la OpenDNS, etc.).  Those users who
have decided to use such services very likely are much more concerned with
malware than the fact that FQDNs associated with malware would be blocked.
 Again, I'm quite willing to include text you wish to propose to capture
alternative viewpoints and criticisms, as that's an important part of such
a document IMHO.

>>   These drafts should clearly spell out the downside of these
>>   methods and their fundamental nature, being MitM attacks.

I'm happy to consider any text you would like to propose, and am quite
willing to include specific notes that some in the community consider the
techniques MitM attacks, in order to try to capture all viewpoints on the
subject.  Feel free to send any proposed text to me via email.

Regards,
Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My comments to the press about RFC 2474

[Livingood, Jason]

>>This sounds like there is potential for crowd sourcing here.
>> 
>> For example, I can tell you nothing about Vonage, but a fair
>> amount about Cox Cable Internet. What you want to know is
>> known, just not (yet) in a way you can easily access.
>> 
>> Would a Yelp type model be appropriate ?
>
>With the understanding that getting accurate and consistent
>measurements is really hard (David Morris's note pointed out
>some of the issues), have a look at http://www.testmy.net/ .
>(Disclaimer: I not only have no affiliation with them other than
>a sign-in to keep data, I haven't bother to find out who they
>really are.)

A few folks met informally over lunch at the last IETF to discuss whether
there was a need for standardization around ISP performance/quality
measurements, and to understand what work was already going.

In the U.S., the FCC is adopting a similar model as in the UK, Sweden, and
other countries.  See http://www.testmyisp.com for info on a pilot test of
some measurements that are planned.

And you can also see http://www.speedtest.net, which is I think the most
popular web-based speed test globally these days (>1.5B tests collected).
They've also made their full dataset available at http://www.netindex.com.
With NetIndex you can click on your state and/or city and see who is tops
in speed.  So for example, if you lived in Redmond, you'd get this
http://www.netindex.com/download/4,201/Redmond/ and in Miami you'd get
this http://www.netindex.com/download/4,70/Miami/. The site also enables a
5-star rating, though it's pretty basic.

Lastly there are sites like http://www.broadbandreports.com/reviews that
provide more detailed ISP reviews.

-- Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My comments to the press about RFC 2474

[Livingood, Jason]

>He's not saying that. He's effectively saying what I'm saying: payment
>models are outside the scope of the standards, which don't require any
>particular payment model in order to perform their job.

+1 to that.  It seems the press struggles to understand that the IETF does
technical standards and not business models.

- Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Soliciting Comments: draft-oreirdan-mody-bot-remediation

[Livingood, Jason]

I¹m looking for direct comments on an updated document, Recommendations for
the Remediation of Bots in ISP Networks, available at
http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03.

I¹m asking here as this doesn¹t really fit neatly into any existing WGs.
(Though we¹ll be posting shortly to the SAAG list.)

Thanks
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: BOFs for Hiroshima

[Livingood, Jason]

Is there a standard interval for such deadlines before an IETF meeting?  As
you noted, this one seems particularly early this time.

Jason


On 8/24/09 12:16 PM, "Marshall Eubanks"  wrote:

> I just wanted to bring to people's attention this (fairly early) cut
> off date for Hiroshima :
> 
> - 2009-09-14 (Monday): Cutoff date for Area Directors to approve BOFs at
> 17:00 PDT (24:00 UTC/GMT).
> 
> This is not that far off. People who are thinking about preparing BOFs
> should get to it.
> 
> Regards
> Marshall
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Livingood, Jason]

> My apologies for the subject line. I'm very disappointed that the
> silent majority of draft authors isn't speaking up. I can't imagine
> that the vast majority of draft authors has absolutely no problems
> with XML2RFC. So I'm assuming they've been ignoring the thread,
> hopefully the new subject line will get some of them to chime in.

I was ignoring it and hoping it went away.  ;-)

I started off using the MS Word template and CRLF to output txt documents.
I found this to be a PITA.  About 9 months ago I switched to xml2rfc and
found it to be great.  Yes, it had a learning curve and the error messages
could be better, but the learning curve is not terrible IMHO and you
eventually get to figure out what the errors mean after awhile.  My
productivity gains in writing and editing drafts is much higher than with MS
Word, though I miss some of Word's built-in change acceptance/rejection
functionality (doing an xml diff is fine, just different).

I also love being able to define both external links and internal anchors so
easily.  Just the internal reference linking has saved me time in post
version -00 docs when I move sections or sentences around and needn't worry
about keeping track of what section was what number.  And it is also nice to
be able to share an HTML version of the doc with co-authors and reviewers,
rather than a txt doc with no working links.

I happen to use Coda on the Mac and use it to write HTML and other scripting
stuff.  YMMV.

> No, it's not. The problem with XML2RFC formatted drafts and RFCs is
> that you can't display them reasonably without using XML2RFC, and
> although XML2RFC can run on many systems in theory, in practice it's
> very difficult to install and run successfully because it's written in
> TCL and many XML2RFC files depend on the local availability of
> references. When those aren't present the conversion fails.

How frequently do any of us work when we're not connected to the Internet?
I just have my XML editor open in one window and the web-based xml2rfc tool
in the other, and every time I make a significant change, I just re-run it
to display an HTML version of the document.  This tends to also make
error-investigation easier since I know what I just changed and can then
review a specific section to find my error.

> those tools. So I write my XML2RFC source by hand. The result is that
> I invariably get error messages that the  and  tags
> don't match properly. This is a problem that is extremely hard to
> debug manually, especially as just grepping for "section" isn't
> enough: there could be a ,  etc somewhere between a
>  and  that breaks everything.

This is most likely a nested section tag problem.  When you write your XML
do you have every "flat" and justified left?  If so, I'd recommend you
tab-in sections and keep your open and close tags lined up, as well as any
tags within each section tabbed in further.

> What we need is the ability to write drafts with a standard issue word
> processor. 

You mean like the template and directions available for MS Word?  Why not
just use that?  

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Call for Participation: "homegate" List

[Livingood, Jason]

This is an open call for participation in the new ³homegate² mailing list,
which is dedicated to discussing issues relating to broadband home gateway
devices.  There has been a BoF request submitted relating to this, which you
can find at 
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF
%20Proposal%20-%20IETF%2075%20-%20v7.pdf.

This work is centered on three key themes: (1) work to improve the network
experience a home user gets, (2) work to keep home networks secure, and (3)
work to bring new functionality to home users.  You can find many more
details in the PDF document that is referred to above.

If this topic is of interest to you, please join our new mailing list at
https://www.ietf.org/mailman/listinfo/homegate.  One of our first
discussions for the mailing list will be to discuss a problem statement,
work on a possible draft charter, and more.

Regards
Jason Livingood
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-livingood-woundy-p4p-experiences-07

[Livingood, Jason]

Thanks for the detailed review, Spencer!  I'll set aside some time next week
to review your comments and then make necessary changes as needed in the
draft to address this in a -08 version.

Regards
Jason


On 5/27/09 9:55 PM, "Spencer Dawkins"  wrote:

> I have been selected as the General Area Review Team (Gen-ART) reviewer for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve
> these comments along with any other Last Call comments you may receive.
> 
> Document: draft-livingood-woundy-p4p-experiences-07
> Reviewer: Spencer Dawkins
> Review Date: 2009-05-27
> IETF LC End Date: 2009-06-16
> IESG Telechat date: (not known)
> 
> Summary: This document is nearly ready for publication as an Informational
> RFC. I did identify some minor issues (listed below) that should be
> considered as this document moves forward in the approval process.
> 
> I also identified some nits, which aren't actually part of the Gen-ART
> review but are included for the convenience of the editor.
> 
> Thanks,
> 
> Spencer
> 
> 1.  Requirements Language
> 
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> Spencer (nit): idnits says no 2119 keywords in the document, so this section
> can be deleted (along with the [rfc2119] reference.
> 
> 2.  Introduction
> 
>Comcast is a large broadband ISP, based in the U.S., serving the
> 
> Spencer (nit): 
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt doesn't list
> "ISP" as an abbreviation that isn't expanded ("please expand on first use").
> 
>majority of its customers via cable modem technology.  A trial was
>conducted in July 2008 with Pando Networks, Yale, and several ISP
>members of the P4P Working Group, which is part of the Distributed
>Computing Industry Association (DCIA).  Comcast is a member of the
>DCIA's P4P Working Group, whose mission is to work with Internet
>service providers (ISPs), peer-to-peer (P2P) companies, and
>technology researchers to develop "P4P" mechanisms, such as so-called
>"iTrackers" (hereafter P4P iTrackers), that accelerate distribution
>of content and optimize utilization of ISP network resources.  P4P
>iTrackers theoretically allow P2P networks to optimize traffic within
>each ISP, reducing the volume of data traversing the ISP's
>infrastructure and creating a more manageable flow of data.  P4P
>iTrackers can also accelerate P2P downloads for end users.
> 
>The P4P iTracker trial was conducted, in cooperation with Pando,
>Yale, and three other P4P member ISPs, from July 2 to July 17, 2008.
>This was the first P4P iTracker trial over a cable broadband network.
>The trial used a Pando P2P client, and Pando distributed a special 21
>MB licensed video file in order to measure the effectiveness of P4P
> 
> Spencer (nit): suggest s/21 MB/21-MB/ for clarity
> 
>iTrackers.  A primary objective of the trial was to measure the
>effects that increasing the localization of P2P swarms would have on
> 
> Spencer (minor): it would be helpful to add a definition for "swarm" -
> everyone kind of knows what you're talking about, but it's not even defined
> in Wikipedia :-) (per
> http://en.wikipedia.org/wiki/Swarm_(disambiguation))...
> 
>P2P uploads, P2P downloads, and ISP networks, in comparison to normal
>P2P activity.
> 
> 
> 3.  High-Level Details
> 
>There were five different swarms for the content used in the trial.
>The first was a random P2P swarm, as a control group.  The second,
>third, and fourth used different P4P iTrackers: Generic, Coarse
>Grained, and Fine Grained, all of which are described in Section 4.
>The fifth was a proprietary Pando mechanism.  (The results of the
>fifth swarm, while very good, are not included here since our focus
> 
> Spencer (minor): "while very good" is slightly more marketing-speak than I
> was comfortable with... the ADs can ignore this comment, of course.
> 
>is on open standards and a mechanism which may be leveraged for the
>benefit of the entire community of P2P clients.)  Comcast deployed a
>P4P iTracker server in its production network to support this trial,
>and configured multiple iTracker files to provide varying levels of
>localization to clients.
> 
> 4.1.  P4P Fine Grain
> 
>The Fine Grain topology was the first and most complex P4P iTracker
>that we built for this trial.  It was a detailed mapping of Comcast
>backbone-connected network Autonomous System Numbers (ASN) to IP
>Aggregates which were weighted based on priority and distance from
>each other.  Included in this design was a prioritization of all Peer
>and Internet transit connected ASNs to the Comcast backbone to ensure
>that P4P tr

Re: Abstract on Page 1?

[Livingood, Jason]

+1 - great idea.


On 3/4/09 10:33 AM, "Margaret Wasserman"  wrote:

> 
> I would like to propose that we re-format Internet-Drafts such that
> the boilerplate (status and copyright) is moved to the back of the
> draft, and the abstract moves up to page 1.
> 
> I don't believe that there are any legal implications to moving our
> IPR information to the back of the document, and it would be great not
> to have to page down at the beginning of every I-D to skip over it.
> If someone wants to check the licensing details, they could look at
> the end of the document.
> 
> Margaret
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

FW: [IP] TODAY: Stop IETF Enactment of Patented Standard for TLS

[Livingood, Jason]

This campaign continues:

-- Forwarded Message
From: Dave Farber 
Reply-To: Dave Farber 
Date: Wed, 11 Feb 2009 08:20:23 -0500
To: ip 
Subject: [IP] TODAY: Stop IETF Enactment of Patented Standard for TLS



Begin forwarded message:

From: Seth Johnson 
Date: February 11, 2009 7:48:37 AM EST
To: d...@farber.net
Subject: TODAY: Stop IETF Enactment of Patented Standard for TLS
Reply-To: seth.john...@realmeasures.dyndns.org


Dave -- for IP, if deemed worthy . . .

Seth Johnson
Outreach Coordinator
New Yorkers for Fair Use


(Urgent.  Send your note TODAY and CONFIRM the automatic reply from
IETF.  Three links below: Glyn Moody's blog, FSF's action page, and
the latest IETF list announcement for TLS-AUTHZ.  -- Seth)


> 
http://www.computerworlduk.com/community/blogs/index.cfm?blogid=14&entryid=1845


Help Fight This Patent-Encumbered IETF Standard

February 10, 2009

Posted by: Glyn Moody

I've written numerous times about the importance of writing to
governments about their hare-brained schemes, but this one is rather
different. In this case, it's the normally sane Internet Engineering
Task Force that wants to do something really daft. The FSF explains:

Last January, the Free Software Foundation issued an alert to efforts
at the Internet Engineering Task Force (IETF) to sneak a
patent-encumbered standard for "TLS authorization" through a back-door
approval process that was referenced as "experimental" or
"informational". The many comments sent to IETF at that time alerted
committee members to this attempt and successfully prevented the
standard gaining approval.

Unfortunately, attempts to push through this standard have been
renewed and become more of a threat. The proposal now at the IETF has
a changed status from "experimental" to "proposed standard".

This is a throwback to the bad old days of sneaking patents into
nominal standards. It is yet another reason why such patents should
not be given in the first place. But until such time as the patent
offices around the world come to their senses, the only option is to
fight patent-encumbered standards on an individual basis. Here are the
details for doing so:

The FSF is again issuing an alert and request for comments to be sent
urgently and prior to the February 11 deadline to i...@ietf.org.
Please include us in your message by a CC to campai...@fsf.org. You
should also expect an automated reply from ietf@ietf.org, which you
will need to answer to confirm your original message.

Here's what I've sent:

I am writing to ask you not to approve the proposed patent-encumbered
standard for TLS authorisation. To do so would fly in the face of the
IETF's fundamental commitment to openness. It would weaken not just
the standard itself, but the IETF's authority in this sphere.

---

> http://www.fsf.org/news/reoppose-tls-authz-standard


Send comments opposing TLS-authz standard by February 11


Last January, the Free Software Foundation issued an alert to efforts
at the Internet Engineering Task Force (IETF) to sneak a
patent-encumbered standard for "TLS authorization" through a back-door
approval process that was referenced as "experimental" or
"informational"
(http://www.fsf.org/news/reoppose-tls-authz-standard/newsitem_view).
The many comments sent to IETF at that time alerted committee members
to this attempt and successfully prevented the standard gaining
approval.

Unfortunately, attempts to push through this standard have been
renewed and become more of a threat.  The proposal now at the IETF has
a changed status from "experimental" to "proposed standard".  The FSF
is again issuing an alert and request for comments to be sent urgently
and prior to the February 11 deadline to i...@ietf.org.  Please
include us in your message by a CC to campai...@fsf.org.  You should
also expect an automated reply from ietf@ietf.org, which you will need
to answer to confirm your original message.

That patent in question is claimed by RedPhone Security
(https://datatracker.ietf.org/ipr/1026/).  RedPhone has given a
license to anyone who implements the protocol, but they still threaten
to sue anyone that uses it.

If our voice is strong enough, the IETF will not approve this standard
on any level unless the patent threat is removed entirely with a
royalty-free license for all users.

Further background for your comment

See the IETF summary:
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html

Much of the communication on the Internet happens between computers
according to standards that define common languages.  If we are going
to live in a free world using free software, our software must be
allowed to speak these languages.

Unfortunately, discussions about possible new standards are tempting
opportunities for people who would prefer to profit by extending
proprietary control over our communities. If someone holds a software
patent on a technique that a programmer or user has to use in order to
make use of a standard, then no one is free without 

RE: [73attendees] Is USA qualifiedfor2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?

[Livingood, Jason]

I recall stats from IETF 71 (which may be out of date).  I believe at
that time, 48% of attendees were from the U.S.  Next was Japan with 9%,
then China with 5.7%.  If I recall correctly, this was a good number of
attendees from China, but I do not know how that compared to IETF 72 or
to IETF 73.  Is the visa issue for visitors from all countries coming to
the U.S., or is this specific to Chinese citizens coming to the U.S.

Jason 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Soininen Jonne (NSN FI/Espoo)
> Sent: Tuesday, November 18, 2008 3:28 PM
> To: ext Joel Jaeggli; Yi Zhao
> Cc: 'David Quigley'; [EMAIL PROTECTED]; 'Nicholas Weaver'; 
> ietf@ietf.org
> Subject: Re: [73attendees] Is USA 
> qualifiedfor2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
> 
> Hi everybody,
> 
> In the IAOC, we have followed the visa situation for 
> different nations closely. It is obviously in the benefit for 
> the IETF to have all the participants that want and need to 
> come to the IETF could also come.
> 
> Historically, the IETF community has indicated the preference 
> of having a big part of the meetings in the North American 
> region. This makes us often come to the USA. Traditionally a 
> major part of the participation is from the North American region.
> 
> Of course, we should periodically check this policy, and also 
> follow the visa situation very carefully.
> 
> I think it would be good for people that were trying to come 
> to the IETF and couldn't to tell the IAD or me what happened. 
> Accurate data is very important.
> 
> Cheers,
> 
> Jonne.
> 
> 
> 
> 
> On 11/18/08 10:08 PM, "ext Joel Jaeggli" <[EMAIL PROTECTED]> wrote:
> 
> > Yi Zhao wrote:
> >> Based on my knowledge, for Chinese citizens there is no 
> any problem 
> >> to get the visa to other countries except US.
> > 
> > I know for a fact that several of your countrymen have had trouble 
> > obtaining visas for other recent IETF destinations.
> > 
> >>  
> >> 
> >> 
> -
> >> ---
> >> 
> >> *From:* [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] *On Behalf Of *David Quigley
> >> *Sent:* Tuesday, November 18, 2008 1:56 PM
> >> *To:* Nicholas Weaver
> >> *Cc:* [EMAIL PROTECTED]; ietf@ietf.org
> >> *Subject:* Re: [73attendees] Is USA qualified 
> >> for2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
> >> 
> >>  
> >> 
> >> Disclaimer: What I say here are my words and don't represent the 
> >> views of my employer.
> >> 
> >>  
> >> 
> >> From what I see here the issues are mostly experienced by Chinese 
> >> citizens. Most of the other countries have reciprocal visa 
> agreements 
> >> with the US. China however doesn't have that agreement 
> with Ireland, 
> >> Sweden, Japan, or the US. Were there similar problems with gaining 
> >> entrance into Ireland? Will there be similar issues with gaining 
> >> entrance into Sweden or Japan?
> >> 
> >>  
> >> 
> >> Dave
> >> 
> >> On Tue, Nov 18, 2008 at 1:40 PM, Nicholas Weaver 
> >> <[EMAIL PROTECTED] 
> > wrote:
> >> 
> >> 
> >> On Nov 18, 2008, at 10:53 AM, Scott Brim wrote:
> >> 
> >> Excerpts from Randy Bush on Tue, Nov 18, 2008 10:39:57AM -0600:
> >> 
> >> [EMAIL PROTECTED]  wrote:
> >> 
> >> I believe our US government would like to grant visas 
> to as many
> >> people as they can. However, if anyone wants to attend 
> a meeting in
> >> the US is granted a visa to come here, then I can 
> imagine there will
> >> be 100 million visa applications for the IETF meeting 
> in CA next year
> >> alone.
> >> 
> >> 
> >> thank you for demonstrating so clearly the jingoistic 
> prejudice at the
> >> us government level that should preclude ietf being 
> held in the united
> >> states.
> >> 
> >> 
> >> How would you solve the problem?  Let 100 million 
> people in on false
> >> pretenses?  I'm not going to defend the behavior of 
> the US government,
> >> but I want you to admit that US immigration has a 
> difficult problem.
> >> Slinging labels around doesn't help.
> >> 
> >>  
> >> 
> >> Remember, the IETF is NOT special.  There are tens of thousands of 
> >> conferences, and they are all pretty much 
> need-to-be-treated equal.  
> >> If the US gave effectively carte blanch to conference 
> attendees, you 
> >> would have no immigration controls, period, as this would be a big 
> >> enough loophole to fly an A380 through.
> >> 
> >> The Visa issue in the US is serious, but how many people 
> are really 
> >> affected by this?
> >> 
> >> We need hard data, because the notion of simply "not holding IETF 
> >> meetings in a terrorist country" is not effective.
> >> 
> >> And if you want to do Visa issues as a criteria, you can strongly 
> >> argue that all IETF meeting SHOULD be in a country where a visa is 
> >> not required for travel for EU, US, Japanese, and Cana

RE: Announcement: New Boilerplate Text Required for allnewSubmissions to IETF

[Livingood, Jason]

+1

Jason 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of David B. Nelson
> Sent: Wednesday, November 12, 2008 11:49 AM
> To: 'Ed Juskevicius'
> Cc: 'IETF Discussion'
> Subject: RE: Announcement: New Boilerplate Text Required for 
> allnewSubmissions to IETF
> 
> > It would be great if the ietf list could be reminded when the new 
> > version of the rather excellent xml2rfc tool is issued, so we don't 
> > need to keep checking back for it.
> 
> It would be even *better* if the cutoff date for acceptance 
> of submissions in the "old" format was conditioned upon 
> having an update to xml2rfc available.  Has anyone given 
> serious consideration to that notion?  If not, consider this 
> a formal request.  Don't start rejecting submissions with old 
> boilerplate until after the required tools updates have been 
> made.  Thanks!
>  
> Regards,
> 
> Dave
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Livingood, Jason]

> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED] 
>
> > Keith - I encourage you to consult with several very large 
> scale email domains around the world to see if they think 
> that DNSxBLs are useful, effective, and in widespread use or not.
> 
> Jason - I encourage you to consult with users whose mail 
> isn't getting delivered, and see whether they think DNSBLs 
> are useful and effective, or whether their mail is 
> effectively being bounced by third parties who aren't 
> accountable for their actions.

The buck ultimately stops with any mail admin (or user of any particular
technology), not the DNSxLs and any other filtering tools they may
choose to employ.  As for consulting with users, you will find me (and
my team) posting (and reading of course) almost daily on the Comcast
section of BroadbandReports and our customer support forum's email
section (http://forums.comcast.net).  I could give you countless other
examples of how I am my team works with senders and customers, and works
to increase our transparency (such as http://postmaster.comcast.net). I
work hard to be in touch with customers, and consider it a centrally
important part of my job to understand how my team's use of technology
affects our customers and other users on the Internet.  Also, I am sure
you would not be surprised to know there is a correlation betewen spam
effectiveness and user satisfaction with email.  Yes, there are always
individual sender problems, but no matter the tool or technology you
always have exceptional use cases that must be worked through.

Regards
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Livingood, Jason]

John C Klensin wrote:

> I've got two separate and unrelated incidents in the last 10
> days in which RBL lists have decided to block some (but not all)
> of Comcast's outbound mail servers.   

Interestingly, this draft is about both blacklists and whitelists.  Many large 
domains maintain whitelists of other large mail domains.  For example, our 
comcast.net outbound servers are all listed here at 
http://postmaster.comcast.net/outbound-mail-servers.aspx and you can get an RSS 
feed of the addresses so that you can get updates.  But every large sender 
tends to do this in an entirely different way.

And, here is how we list our dynamic IP address space, at 
http://postmaster.comcast.net/dynamic-IP-ranges.aspx and in RSS feed at 
http://postmaster.comcast.net/dynamic-ip-ranges.xml.  In the case of dynamic 
space, several DNSxBLs exist that aggregate ISP dynamic IP space to make it 
easier on large domains to put all of those together.

Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Livingood, Jason]

-Original Message-
From: [EMAIL PROTECTED] on behalf of Keith Moore
Sent: Sat 11/8/2008 2:50 PM
To: John Levine
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

Keith Moore wrote:
 
>and there's a billion and a half users whose email is being degraded by
>such mechanisms.

>if you ask them whether they want to not receive spam, they'll say yes.
> if you ask them whether they want their incoming mail filtered on the
>basis of unsubstantiated rumor and unreliable identifiers, they'll say no.

Keith - I encourage you to consult with several very large scale email domains 
around the world to see if they think that DNSxBLs are useful, effective, and 
in widespread use or not.

Regards
Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Livingood, Jason]

> Incidentally, although it may still be the conventional 
> wisdom in the IETF that DNSBLs don't work and aren't useful, 
> in the outside world where 95% or more of mail is spam, 
> they're essential tools to run a mail server.  Although there 
> are indeed lots of stupid DNSBLs, those aren't the ones that 
> people use, and there are widely used ones that have 
> vanishingly low false positive rates that let you knock out 
> most of the spam cheaply so you can afford to do more 
> expensive filtering on what's left.  Spamhaus estimates, 
> based on the systems that pay for their data feeds, that 
> there are about 1.4 billion mailboxes whose mail is filtered 
> using their lists, and they're the biggest but hardly the 
> only popular high quality DNSBL.  It's pretty clear that 
> there are a lot more mail systems that do use DNSBLs than don't.

As an operator of a large mail domain, I'd like to reiterate John's
comments above.  DNSBLs work, are very cost (and computationally)
effective, and are in widespread use.

Regards
Jason
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Social Event - Transportation / Final Logistics Update

[Livingood, Jason]

IETF 71 - Social Event Advisory
 
The social begins at 7:00pm and runs until 10:30pm.
 
This is a reminder regarding transportation from the Marriott to the
Philadelphia Art Museum.  We are providing buses (that look like
trolleys, for what that's worth).  These buses will run in a continuous
loop between the hotel and the museum, with the first one leaving at
6:45pm.  Thus, it will be easy for you to leave the hotel for the museum
and leave the museum to return at just about any time.  There is at
least one handicap-accessible bus.
 
FROM THE HOTEL: To board the buses from the hotel, please use the
Filbert Street entrance of the hotel, where the hotel check in and
curved driveway is located.  There will be Comcast personnel on-site to
assist in boarding buses and getting buses underway between
approximately 6:45pm and 8:15pm.  There will be Comcast personnel
on-site to receive the buses at the museum and to assist you on your
return throughout the evening.
 
NO ADMISSION TO THE MUSEUM WITHOUT YOUR SOCIAL TICKET.  The perforated
stub will be torn off when you enter the museum, and the remaining part
of the ticket will be turned in upon your departure, in exchange for a
gift on your way out.
 
There will be a coat check and a bag check at the museum.  There is also
a WiFi network at the museum.
 
Should you make your way to the museum on your own, entry is from the
west entrance, which is in the back of the museum.  Please note that
this is a 30 minute walk from the hotel.  You can of course get taxi
service to the museum easily, and if you drive, there is ample parking
behind and around the perimeter of the museum.
 
Regards
Jason Livingood
 
http://ietf71.comcast.net/?page_id=12
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Win Ice Hockey Tickets

[Livingood, Jason]

And the winners of the tickets are

1 - KURT ZEILENGA
2 - W. MATTHYS MEKKING

The winners should stop by the Comcast t-shirt table ASAP to pick up
their tickets.  Each winner received two club box tickets.  If the
tickets are not claimed by 3:00pm Wednesday, we will need to select
another winner.

Regards
Jason Livingood
Comcast


> -Original Message-
> From: Livingood, Jason
> Sent: Friday, March 07, 2008 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: Win Ice Hockey Tickets
> 
> Thanks to HP, our business partner in releasing Comcast 
> SmartZone, we are raffling four club box tickets to the 
> Philadelphia Flyers ice hockey game on Wednesday night.  
> We'll be raffling TWO sets of two tickets each.
> 
> To enter the raffle, drop a business card in the entry box at 
> the Comcast table in the registration area.  This is the same 
> table where you will be picking up your t-shirts, starting on Sunday.
> 
> The raffle will close on Tuesday, 3/11, at 3:00pm ET, and 
> winners announced at that time.
> 
> See you in Philly!
> 
> Jason Livingood
> Comcast
> 
> PS - The game is at the Wachovia Complex, and is accessible 
> via subway from the Marriott.
> http://www.comcastspectacor.com/ParkingAndDirections/publicTra
> nsportatio
> n.asp
> 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 71st IETF - Hotels and Social Event

[Livingood, Jason]

Due to high demand for the already sold-out social, the wait list will
close today.  We will probably have fewer cancellations than people
already on the wait list, which is why we are taking this step with AMS.

Regards
Jason Livingood
Comcast 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of IETF Secretariat
> Sent: Monday, February 25, 2008 2:07 PM
> To: IETF Announcement list
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: 71st IETF - Hotels and Social Event 
> 
> 71st IETF Meeting
> Philadelphia, PA, USA
> March 9-14, 2008
> Host: 
>   Comcast
> 
> The Marriott still has a limited number of rooms available at 
> the group rate but is currently sold out on the night of 
> Thursday, March 13.  The Doubletree Hotel is currently sold out.  
> 
> Please note that the Marriott will have a large number of 
> people checking out on Sunday, March 9 which will mean rooms 
> will not be available to check into until the hotel's 4:00pm 
> check-in time.
> 
> We have secured an additional block of rooms at the Hilton 
> Garden Inn, which is approximately three blocks from the 
> Marriott.  The Garden Inn is holding this block at the IETF 
> group rate of $189 until Friday, February 29, 2008. 
> Additional information on the Garden Inn can be found at:
> http://www.ietf.org/meetings/71-hotels.html
> 
> The social event is currently sold out.  If you have already 
> registered and paid for your IETF registration and would like 
> to be put on a waiting list for social event tickets, you can 
> do so at:
> https://www.amsl.com/ietf/socialwaitlist.py
> 
> For those who need visas, don't forget to request your letter 
> of invitation.  Information can be found at: 
> http://www.ietf.org/meetings/71-invite_letter.html
> 
> Only 13 days until the Philadelphia IETF! 
> Online registration for the IETF meeting is at: 
> http://www.ietf.org/meetings/71-IETF.html
> 
> ___
> IETF-Announce mailing list
> [EMAIL PROTECTED]
> http://www.ietf.org/mailman/listinfo/ietf-announce
> 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 71st IETF - Early Bird Registration Cutoff

[Livingood, Jason]

BTW, the direct payment URL is https://www.amsl.com/ietf/ietfpayment.py

Jason

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of IETF Secretariat
> Sent: Wednesday, February 27, 2008 6:02 PM
> To: IETF Announcement list
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: 71st IETF - Early Bird Registration Cutoff 
> 
> 71st IETF Meeting
> Philadelphia, PA, USA
> March 9-14, 2008
> Host: 
>   Comcast
> 
> Early-Bird Registration cutoff is Friday, 29 February 2008 at 
> 17:00 ET (22:00 UTC/GMT).
> 
> If you register and pay in full prior to 17:00 ET (22:00 
> UTC/GMT), Friday
> 29 March 2008 your registration fee is $635 USD.
> 
> If you register and/or pay after 17:00 ET (22:00 UTC/GMT), 
> Friday 29 March 2008 your registration fee is $785 USD.
> 
> Full-time students fee is $150 USD with on-site proof of ID, 
> regardless of when you register and pay.
> 
> Only 11 days until the Philadelphia IETF! 
> Online registration for the IETF meeting is at: 
> http://www.ietf.org/meetings/71-IETF.html
> 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

IETF 71 Social Ticket Update - Unpaid Tickets and Waitlist

[Livingood, Jason]

As noted previously, the IETF 71 Social is currently "sold out."
However, of the 500 tickets available, 105 people have reserved tickets
but not yet paid.  An email just went out to those people asking them to
pay for their social ticket no later than 11:30 a.m. ET, Monday, March
10th.  At 11:31 a.m., all unpaid tickets will be released to the waiting
list that AMS is administering at
https://www.amsl.com/ietf/socialwaitlist.py. 
 
Please reply or contact me personally if you have any questions.

Regards

Jason Livingood
Comcast
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

IETF 71 Social Reminder: Just a Few Tickets Left

[Livingood, Jason]

This is a reminder that if you have not already purchased your social
ticket and would like to attend, you should do so *immediately.*  This
event is strictly limited to 500 people, and we currently have 467
registered.  So just 33 tickets remain available as of a few minutes
ago.

To buy your social ticket:
https://www.amsl.com/ietf/socialtickets.py

For more info on the social:
http://ietf71.comcast.net (and click on "Social")

Regards

Jason Livingood
Comcast IETF 71 Planning Team
(and co-chair of speermint)
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

RE: IETF 71 - no room at the inn at all on Thursday

[Livingood, Jason]

Our site is still down for the move at the moment, should be back up
soon.  That site lists all of the nearby hotels, most of which have a
special Comcast rate.  I would simply ask that you read the "special
rate notice" at the bottom of our hotels page and let me know if I can
assist further.

Jason 

> -Original Message-
> From: John L [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 13, 2008 8:19 PM
> To: Mikko Saarnivala
> Cc: Livingood, Jason; ietf@ietf.org
> Subject: Re: IETF 71 - no room at the inn at all on Thursday
> 
> >> I am sure you can find something to stay for the duration.
> 
> The question isn't whether there's other hotels in 
> Philadelphia, of course there are, although it wouldn't be 
> easy to find something as nice, and close as the Doubletree 
> for $169 which is quite a good price for Center City.
> 
> I was wondering why the Doubletree doesn't have the block of 
> rooms available that they promised to the IETF.  The 
> reservation agent said she saw the room block, but it didn't 
> have rooms Thursday like it did for the rest of the week.  
> Unless there's a vast number of IETFers only staying Thursday 
> night, which seems rather unlikely, Hilton didn't provide the 
> room block they said they would.  I would have thought their 
> long term agreement with the IETF would prevent just this 
> kind of problem.
> 
> R's,
> John
> 
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

IETF 71 Microsite Down / Moving (was "no room at the inn")

[Livingood, Jason]

In the other thread, I reminded folks of our IETF 71 microsite @ 
http://ietf71.comcast.net and the list of hotels there.  Please excuse
the fact that this site is off-line for a few hours right now, though it
should be back up in a few hours if all goes according to plan (famous
last words, I know).  We're in the process of moving the server from our
old building to our new building.  You'll notice this new building in
the skyline when you come into the city too -- see this site for some
cool pics from construction to current-day:
 
http://phillyskyline.com/bldgs/comcast/i2.htm
 
Regards
Jason Livingood
--- Begin Message ---
--- End Message ---
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

RE: IETF 71 - no room at the inn at all on Thursday

[Livingood, Jason]

I am sure you can find something to stay for the duration.  From
http://ietf71.comcast.net/?page_id=5 some added suggestions:

1 - Loews, across the street
2 - Marriott Courtyard, 1/2 block
3 - Marriott Residence Inn, 1/2 block
4 - Hilton Garden Inn, 2-3 blocks
and about 10 other suggestions as well.

Regards
Jason 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of John Levine
> Sent: Tuesday, February 12, 2008 8:53 PM
> To: ietf@ietf.org
> Subject: Re: IETF 71 - no room at the inn at all on Thursday
> 
> > I'm on the phone to Doubletree reservations trying to make a 
> > reservation for the 9th to the 14th, and she tells me that 
> there are 
> > no rooms in the IETF block on the 13th, ...
> 
> She came back and said there are no rooms at the Doubletree 
> at all on the 13th, not at the rack rate or anything.  I 
> guess I'm leaving on Thursday.
> 
> The block rate at the Marriott is long gone, and all that's 
> left is the
> $389 rack rate.
> 
> Poking around on the varions hotel web sites, I see a $104 
> rate at the Latham on 17th st, or $126 at the Rodeway Inn on 
> Walnut St, or $169 at the Hampton Inn on Race St, each about 
> the same distance as the Doubletree.
> 
> R's,
> John
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

RE: IETF 71 - no room at the inn on Thursday

[Livingood, Jason]

You may want to check out the URL below on our IETF 71 microsite for
some other hotel suggestions.  Ray or Marcia may have more info but this
list is pretty comprehensive.

http://ietf71.comcast.net/?page_id=5 

Jason

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of John Levine
> Sent: Tuesday, February 12, 2008 8:38 PM
> To: ietf@ietf.org
> Subject: IETF 71 - no room at the inn on Thursday
> 
> I'm on the phone to Doubletree reservations trying to make a 
> reservation for the 9th to the 14th, and she tells me that 
> there are no rooms in the IETF block on the 13th, so I have 
> to pay $274 rather than $169 for that night.
> 
> Has anyone else run into this problem?  Can Ray get our new 
> friends at Hilton to make the block rectangular and have 100 
> rooms every night, not just some of them?
> 
> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The 
> Internet for Dummies", Information Superhighwayman wanna-be, 
> http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, 
> please", said Tom, revealingly.
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

IETF-71 Social Reminder / Update

[Livingood, Jason]

Just wanted to remind IETF-71 attendees that the social event will be
strictly limited to 500 people.  As of now, we are about 50% full, which
means we're booking up somewhat more rapidly than expected.  

Thus, if you would like to attend, please consider registering soon.
All of the details are at http://ietf71.comcast.net/?page_id=12 and you
can get to the registration link from there or via the IETF website at
http://www3.ietf.org/meetings/71-IETF.html.  

Date: Tuesday, March 11, 2008
Time: 6:30pm - 10:00pm
Cost: $30
Location: Philadelphia Museum of Art
Transportation: Shuttle buses will take attendees the 1.5 miles from the
hotel to the social and back.

Full Museum Access: Guests will have access nearly all parts of the
museum, in addition to the special Frida Khalo exhibit.

Bar: Open bar, including a selection of premium beers, wine, and liquor.

Food: An excellent selection of food, with some influenced by the
special Frida Khalo exhibit, and including vegetarian selections.  Some
of the foods will include lamb chops, crab cakes, filet of beef, sushi,
duck, shrimp, and more.

In all seriousness, this will be a social to remember and we're going to
great lengths to ensure that it is a lot of fun, with great food, drink,
and socializing.

Hope to see you there!

Regards
Jason Livingood
Comcast

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF 71 - Hotel Booking Reminder

[Livingood, Jason]

Since folks may have missed some of the traffic in December, please take
note of the hotel booking advisory at our IETF-71 microsite @
http://ietf71.comcast.net/?page_id=5.

Specifically ---> If you are considering arriving on the *Saturday*
before IETF 71 (March 8, 2008), please be aware that the Philadelphia
Flower Show is taking place next door at the Philadelphia Convention
Center.  This is a very popular show which attracts over 250,000 people
each year.  It is run by the Pennsylvania Horticultural Society, and is
the largest indoor flower show in the world.  That show ends on the
Sunday that IETF 71 begins, so most flower show visitors will be
checking out the same day that most IETF people will be checking in.
However, if you plan to arrive early, contact the hotel ASAP to make
your reservation and understand that the Saturday rate may be somewhat
higher (or unavailable) due to high demand. 

At http://ietf71.comcast.net/?page_id=5 we have published a list of lots
of nearby hotels, for your information and as a **supplement** to the
official venue hotels listed on the IETF website at
http://www.ietf.org/meetings/71-hotels.html.

Please be advised that we also have some travel logistics advice at
http://ietf71.comcast.net/?page_id=4 and we'll soon have very important
information on all of the nearest and best bars, restaurants, etc.  :-)


Recent posts include info on where to find a good cheese steak,
vegetarian food, and how to download audio/web tours.

BTW, you can also set your RSS reader to
http://ietf71.comcast.net/?feed=rss2 to track site updates
automatically.

Regards
Jason


Jason Livingood
Comcast - IETF 71 Host

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IETF71 hotel noise warning on Marriott web pages

[Livingood, Jason]

 
> Is that going to be a large suite, a converted meeting room, 
> or a room large enough to accommodate several hundred of us 
> at the same time?  The question is important if it is 
> reasonable to assume that all other small meeting spaces in 
> the hotel (at least  those not specifically covered by 
> contract) are going to be closed, noisy, dusty, or otherwise unusable.

Ray probably has photo mockups of the space that he could share.

> Between this and apparent efforts by the IAOC, IESG, and 
> sponsor to deliberately disrupt the network, this is 
> beginning to sound like the meeting to miss.

Well, we certainly hope not!  I think Russ' proposal was to do something
controlled for a very brief time during the plenary.  I know we've asked
to reconsider that as well - fearing that attendees would have the same
reaction that you just articulated.

Jason Livingood
Comcast

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Westin Bayshore throwing us out

[Livingood, Jason]

They will have a special bar area setup for attendees.  There are also
several other bars inside the hotel building (including a sports bar)
and probably 10 - 15 bars within a 1 to 2 block radius.  I believe the
liquid consumption needs of attendees will be easily accomodated.  :-)

We'll be posting at http://ietf71.comcast.net a guide to all of the
local bars and the distances from the hotel lobby in the coming weeks
and months before IETF 71.  

Jason 

> -Original Message-
> From: Adam Roach [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 29, 2007 5:11 PM
> To: Livingood, Jason
> Cc: Fred Baker; Cullen Jennings; Pete Resnick; ietf@ietf.org
> Subject: Re: Westin Bayshore throwing us out
> 
> On 11/29/07 2:00 PM, Livingood, Jason wrote:
> > ...[T]he renovation in Philly for IETF 71 (discovered after 
> the venue decision I believe) is of... the bar.
> 
> Well, there goes any hope of getting anything useful done in 
> Philly. :)
> 
> /a
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF 71 Info

[Livingood, Jason]

FYI, in addition to the typical info that will be on the web in advance
of IETF 71, we setup a site that will soon include additional logistical
and city information.  It's pretty basic at the moment, but you can
subscribe to the RSS feed if you like.  The hope is to provide a little
extra info for attendees to make coming to IETF 71 a little easier for
attendees.

The URL is http://ietf71.comcast.net

Much more will be added to this site once IETF 70 has concluded (and I
will probably work on it while in Vancouver).  Email me privately if
there is anything you think is really useful for attendees.

Regards
Jason

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Hotel selection

[Livingood, Jason]

> From: Fred Baker [mailto:[EMAIL PROTECTED] 
> One question I would ask the peanut gallery is: if we were to 
> pick a small set of venues to return to, which would we pick? 
> The ones I might think of would include our recent venues in 
> Paris and Prague, the Minneapolis Hilton, the facility we 
> were at in Dallas last year (although restaurants weren't 
> very convenient)

I would actually vote strongly against venues such as the Dallas venue.
Given that we have over 1,000 people coming into each venue, it seems
odd to expect everyone to rent cars and otherwise go somewhere that is
relatively remote from other services.  

IMHO, ideal venues are in city centers, where people can walk from the
venue to a wide variety of other hotels and restaurants, and where
public transportation is available to connect between airports and
regional rail systems and to other parts of the venue's city.  This
tends to decrease the travel costs and hassles for attendees, among
other benefits.

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Westin Bayshore throwing us out

[Livingood, Jason]

> For the record, Ray was aware of this renovation, and tells 
> us that there will be renovation ongoing in Philadelphia as 
> well. 

Ray can comment more, but the renovation in Philly for IETF 71
(discovered after the venue decision I believe) is of some of the common
areas in the bar and does not involve renovations to the guest rooms.  I
will also note that in Philadelphia, there are a plethora of hotels to
choose from within a block or two walk from the venue as well (in
addition to good subway systems, etc.).

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Westin Bayshore throwing us out

[Livingood, Jason]

> -Original Message-
> From: Cullen Jennings [mailto:[EMAIL PROTECTED] 
> Actually, I'm interested in a more basic thing. We usually 
> put a large load on a hotel. Why don't our contracts insist 
> that the hotel not be undergoing significant renovation 
> during the meeting. 

One of the problems is that the venue agreements are made pretty far in
advance, and hotels make renovation decisons on shorter timeframes.  So
you may make a venue selection 1 1/2 years before a meeting, and find
out 1 year before the meeting of a renovation.  

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Geography briefiengs for IETF required

[Livingood, Jason]

Elisabeth -

Thanks you for your gracious and kind reply.  I appear to be guilty of
dropping the word "Continental" from the summary of results, and
apologize for apparently offending you on this point.  The results
summary should have read "Continental Europe."  

Those who took the survey will have noticed (and this is available in
the downloadable results) that we in fact had listed a "U.K." choice as
well as a "Continental Europe" choice. 

Regards
Jason

> -Original Message-
> From: Elisabeth Porteneuve [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, October 07, 2007 3:53 AM
> To: Livingood, Jason
> Cc: Elisabeth Porteneuve (labo)
> Subject: Geography briefiengs for IETF required
> 
> Re your message posted to IETF list:
> 
> > Subject: IETF 71: Results of Social Venue Survey
> > From: "Livingood, Jason" 
> > Date: Sat, 6 Oct 2007 22:20:24 -0400
> 
> [...]
> 
> 6.Respondents were from a range of geographic locations:
>   a.  U.S.: 55%
>   b.  Europe: 27%
>   c.  Asia: 7%
>   d.  U.K.: 4%
> 
> 
> Last time I checked the UK was in Europe. You may wish to add 
> geography brifiengs to the IETF attendees (from the US?), and 
> especialy those who make surveys.
> 
> Elisabeth Porteneuve
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF 71: Results of Social Venue Survey

[Livingood, Jason]

I would like to thank all of you in the IETF community that participated
in this survey.  We were delighted that 245 people took the time to do
so.  We asked both about what people liked and disliked about IETF
socials generally, as well as which of the two venues we narrowed our
choices to they liked best (we of course visited/investigated many
more).

In terms of a venue, there was clearly more interest in the Philadelphia
Museum of Art, and so we have selected this venue and are now working
out all of the agreements to make this happen.

PDFs of the raw survey results are available to anyone who wishes to
view them.  These may be particularly useful to future IETF meeting
sponsors, and many of the comments are quite interesting.  These can be
found at
http://ietf71.comcast.net/premtgsurvey/IETF71-SocialVenueSurvey.zip.
Please note that we will be publishing more meeting & logistical info
over time at http://ietf71.comcast.net (you can also set your RSS reader
to http://ietf71.comcast.net/?feed=rss2 to pick up any changes
automatically).

Key survey findings:
1.  Of the respondents, the large majority plan to attend IETF 71.
a.  83%, or 204 people, plan to attend.
b.  15%, or 38 people, are undecided.
c.  1%, or 3 people, will not attend.

2.  Of the respondents, many are undecided on whether they will
attend the social and appear to decide whether to do so at each IETF
meeting.
a.  59%, or 143 people, sometimes attend depending on the
individual event.
b.  39%, or 94 people, always attend.
c.  3%, or 6 people, never attend.
d.  1 person would only attend if they event was certain to
be IPv6-compliant.

3.  The most important parts of attending a social event for
attendees are:
a.  Meeting people / talking to people
b.  Good food
c.  Visiting an interesting venue
d.  Stuff to see / do
e.  Open bar

4.  Of secondary importance for the event (less important than
above):
a.  Music
b.  Affordability / value

5.  The least important item for an event was music.

6.  Respondents were from a range of geographic locations:
a.  U.S.: 55%
b.  Europe: 27%
c.  Asia: 7%
d.  U.K.: 4%
e.  Canada: 3%
f.  Middle East: 1%
g.  2% lived "in the network," "on the moon," or in some
other "secret" locale.

Regards
Jason Livingood

> -Original Message-
> From: Livingood, Jason [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 23, 2007 3:48 PM
> To: ietf@ietf.org
> Subject: IETF 71: Social Venue Survey
> 
> Hello -
> 
> I am on the planning team for the sponsoring organization of 
> IETF 71. We are continuing to get ready for this event.  
> 
> We would like to solicit the community's feedback on the 
> possible locations of the social venue and what is important 
> to you for such events.  There are 6 questions, so it should 
> only take you a few minutes to complete.
> 
> To take the survey, go to:
> http://www.surveymonkey.com/s.aspx?sm=hcr9IMRQmHOe74i_2bMChaOg_3d_3d
> 
> Thank you in advance if you take the time to complete a survey.
> 
> Regards
> Jason Livingood
> 
> PS - This survey will be open until September 5, 2007.
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF 71: Social Venue Survey

[Livingood, Jason]

Hello -

I am on the planning team for the sponsoring organization of IETF 71. We
are continuing to get ready for this event.  

We would like to solicit the community's feedback on the possible
locations of the social venue and what is important to you for such
events.  There are 6 questions, so it should only take you a few minutes
to complete.

To take the survey, go to:
http://www.surveymonkey.com/s.aspx?sm=hcr9IMRQmHOe74i_2bMChaOg_3d_3d

Thank you in advance if you take the time to complete a survey.

Regards
Jason Livingood

PS - This survey will be open until September 5, 2007.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Prague (Praha) street maps and hotels (was Re: IETF 68 hotel full)

[Livingood, Jason]

Looks like the hotel is on the far eastern edge of the Jewish Quarter
(or just to the east of it), so there may be other hotels in that area.
The Old Town is also close by (Stare Mesto) and is probably a good area
to look for hotels as well.

Jason 

> -Original Message-
> From: Elwyn Davies [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 20, 2006 6:05 AM
> To: ietf@ietf.org
> Subject: Prague (Praha) street maps and hotels (was Re: IETF 
> 68 hotel full)
> 
> Search for Praha postcode 18600 or the Florenc metro station 
> which is just nearby (slightly south of hotel).
> 
> Link to maps centred on hotel:
> http://www.multimap.com/map/browse.cgi?lat=50.0922&lon=14.439&;
> scale=5000&icon=x
> (links to some hotels relatively nearby)
> 
> www.mappy.com finds about 30 hotels fairly close to the 
> Hilton (search for the Florenc metro, zoom out a couple of 
> times and search for hotels)
> 
> www.map24.com is good for restaurants (search for praha 18600)
> 
> Elwyn
> 
> > On 12/19/06, Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> >> BTW, www.mappy.com is pretty good for maps and itineraries 
> in Europe.
> >>
> >> Brian
> >>
> >> John Levine wrote:
> >> >>I'm having trouble finding "Pobrezni 1 186 00 Prague 8 
> Czech Republic"
> >> >>with online maps.
> >> >
> >> >
> >> > I believe hotel is toward the west end of the street, near the 
> >> > bridge to the island in the river:
> >> >
> >> > 
> >> 
> http://maps.google.com/maps?f=q&hl=en&e=UTF8&om=1&ie=UTF8&z=16&ll=50.
> >> 092682,14.443717&spn=0.009375,0.016673
> >>
> >> >
> >> > On the other hand, the Hilton web site just offered me a 
> room for 
> >> > IETF week at E152 which appears to be the IETF rate, so it's not 
> >> > all that sold out.
> >> >
> >> > Regards,
> >> > John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet
> >> for Dummies",
> >> > Information Superhighwayman wanna-be, http://www.johnlevine.com, 
> >> > Mayor "More Wiener schnitzel, please", said Tom, revealingly.
> >> >
> >> >
> >> > ___
> >> > Ietf mailing list
> >> > Ietf@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/ietf
> >> >
> >>
> >> ___
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >>
> >
> >
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Interworking between 2 different vendors' Softswitches

[Livingood, Jason]

You probably want to post your question to two different WG mailing
lists.  The first is speermint and the second is enum.
 
http://www.ietf.org/html.charters/speermint-charter.html
 
http://www.ietf.org/html.charters/enum-charter.html
 
Regards
Jason




From: Ramirez, Luis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 30, 2006 2:31 PM
To: ietf@ietf.org
Subject: Interworking between 2 different vendors' Softswitches 


Hello,
 
We are trying to deploy an IMS network but we have an
interoperability problem between 2 Softswitches that we have in our NGN
network, one of them supports SIP-I (based on ITU-T Q.1912.5) and the
other one supports SIP-T (based on RFC 3398). We need to define which
standard is better, thinking on that our next step is to implement an
IMS network. Could you please give me any suggestion with the related
argumentation?
 
Thanks a lot,
 

Luis Carlos Ramirez Alonso
_

Siemens S.A.
Communications
Fixed Networks
Av. Don Diego Cisneros Edif. Siemens, Caracas
Venezuela
Tel. +58.212.203.8298
Fax +58.212.203.8636 
Cel. +58.412.203.8724
E-Mail: [EMAIL PROTECTED]
 
Website: http://www.siemens.com/surpass
 
 
The new company Nokia Siemens Networks is expected to start
operations by January 1, 2007, subject to customary regulatory
approvals, the completion of standard closing conditions, and the
agreement of a number of detailed implementation steps
 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IETF Meeting Network and Other Technical Requirements

[Livingood, Jason]

Does this section mean that 802.11a is specifically not supported?  Any
idea if the wifi network at the Dallas meeting will be better than in
Vancouver?

Regards
Jason

3.3.  Wireless Network

   IEEE 802.11b/g service must be available in all the meeting rooms (as
   identified by the Secretariat), the registration area, and the
   terminal room.

   The WLAN coverage must also be sufficient in additional common spaces
   including hotel lobby, hotel bar, hotel restaurant, most commonly
   used hallways, etc.

   IEEE 802.11a coverage must be also available in as many as the above
   named spaces as possible, focusing on the most dense user
   requirements (plenary meeting room) first.

   The WLAN must provide fully open (unsecured) wireless access and may
   provide additional secured (WEP, 802.11i) services.

   Must support IPv6. 

> -Original Message-
> From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 01, 2006 4:07 AM
> To: ietf@ietf.org
> Subject: IETF Meeting Network and Other Technical Requirements
> 
> Hi all,
> 
> I've submitted on Monday a new document, containing the 
> technical aspects that were previously embedded in the 
> venue-selection one, until I decided to take the technical 
> part out. Consequently, it has already some inputs that come 
> from comments to the previous existing "join" text and which 
> actually was also being prepared by Karen Odonoghue.
> 
> Until it is available in the IETF site, you can get it at:
> http://www.consulintel.euro6ix.org/ietf/draft-palet-ietf-meeti
> ng-network-req
> uirements-00.txt
> 
> The document is still not so good as I wished but didn't 
> wanted to miss the publication dead line.
> 
> And the most important issue right now is to get your inputs 
> so we can make it much better ;-)
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> **
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf