Re: 66th IETF - Registration and Hotel Accommodations

[Pete Resnick]

On 4/20/06 at 4:21 PM -0400, John C Klensin wrote:

--On Thursday, 20 April, 2006 14:15 -0500 Pete Resnick 
<[EMAIL PROTECTED]> wrote:


Does anybody know the walking distances to the venue from hotels on 
the east side? I plan to vacation there the week before, and both 
the Hôtel XIXe siècle and the Hôtel Place d'Armes look charming and 
within a block or two (and I can get a decent rate).


Of course, nobody has yet answered my question. :)

(For the record, the Holiday Inn Select Centre-Ville seems really 
close, and relatively cheap.


And now perhaps may be sold out. Ah well.


 The St-James is also close, but now so cheap. :-) )


"Not" so cheap, I meant, of course. The St-James is a *rather* 
impressive looking hotel.


This is the first time in a long time I'm seriously considering 
*not* staying at the conference hotel. I'm not sure I see the point.


Free Internet access?


Seen at the other hotels I've been looking at.

Same bar most other people are trying to meet in (as far as I can 
tell from the web site, the hotel's (only?) bar closes at 11PM. 
There might be other options, but, if they exist, it isn't possible 
to tell from the information we have been supplied.


As far back as I can remember (which starts about 11 years ago for 
me), at every IETF where *the* hotel was not directly connected to 
the meeting venue (Vienna, Yokohama, Montreal), and even some where 
the bar was a long distance from the meeting rooms, the hotel bar 
does not get used nearly to the extent that it does in other 
circumstances. I find more often that people gather outside of the 
meeting rooms and wander to whatever watering-hole is closest. I 
suspect that's going to be the Intercontinental bar or some other 
places nearby at this meeting. But again, it's hard to tell how far 
things really are.


pr
--
Pete Resnick 
QUALCOMM Incorporated
pl

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

Re: 66th IETF - Registration and Hotel Accommodations

[John C Klensin]

--On Thursday, 20 April, 2006 14:15 -0500 Pete Resnick
<[EMAIL PROTECTED]> wrote:

> On 4/20/06 at 8:04 AM -0700, Ole Jacobsen wrote:
> 
>> There is at least one hotel closer to the venue also, the
>> InterContinental.
> 
> The Delta seems to be 3 (rather long) blocks west and the
> InterContinental just across the street to the southwest.
> 
> Does anybody know the walking distances to the venue from
> hotels on the east side? I plan to vacation there the week
> before, and both the Hôtel XIXe siècle and the Hôtel Place
> d'Armes look charming and within a block or two (and I can get
> a decent rate).
> 
> (For the record, the Holiday Inn Select Centre-Ville seems
> really close, and relatively cheap. The St-James is also
> close, but now so cheap. :-) )

While I don't have the information you are looking for, I note
two things about this process and announcement:

(1) This is the first time I can remember that the
meeting has not been at the hotel and the
announcement/posting has not contained any information
at all about topics like relative locations of the hotel
and conference facility or related logistics.  Brian's
"said to be a short walk" is reassuring, but it would be
much better if that information were available from the
web site and more precise there.  The fact that the
location map, which is supposed to be in PDF, can't be
opened by Acrobat doesn't help much.

(2) While it probably isn't the first time, I remember
few, if any, cases in which we have been given the
option of exactly one hotel (a hotel with a room block
too small to accommodate all IETF attendees) and
insufficient information for people to track down
alternatives, at least without a lot of questions
similar to those Pete asks above.

FWIW, if this represents a trend of meeting and logistics
plannings and announcements under the new regime, it is not one
that I find reassuring.

> This is the first time in a long time I'm seriously
> considering *not* staying at the conference hotel. I'm not
> sure I see the point.

Free Internet access?  Same bar most other people are trying to
meet in (as far as I can tell from the web site, the hotel's
(only?) bar closes at 11PM.  There might be other options, but,
if they exist, it isn't possible to tell from the information we
have been supplied.

 john





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

Re: Impending publication: draft-iab-idn-nextsteps-05

[Jeffrey Hutzelman]

On Thursday, April 20, 2006 03:05:43 PM +0200 Simon Josefsson 
<[EMAIL PROTECTED]> wrote:



   An example of the type of change that appears to be just a small
   correction from one perspective but may be problematic from another
   was the correction to the normalization definition in 2004 [Unicode-
   PR29].

I believe it should be noted here that this was discovered after
Unicode 3.2 was published, and consequently doesn't apply to the
original Unicode 3.2.  I.e., change 'PR29].' into:


Corrigendum #5, which fixes the inconsistency causing the problem described 
in PR29, _does_ apply to versions of Unicode from 3.0.0 through 4.0.1, 
including 3.2.


It is also worth noting that even for implementations which were based on 
the (normative but incorrect) text of the original 3.2 spec rather than the 
(non-normative but correct) sample code, changing to the corrected model 
will not "break backwards compatibility in Unicode for most European 
languages", because those combining sequences which trigger the 
inconsistency "do not constitute well-formed text in any known language" 
(Unicode corrigendum #5).


On the other hand, potential security issues caused by instability in the 
original (erroneous) definition are at least as serious as the potential 
incompatibilities caused by the change.


I suggest that folks who are interested in this issue read PR29 for 
themselves, rather than relying on Simon or myself for information.






I suggest replacing 'incompatibilities.' with:

   incompatibilities, despite that the change does not apply to the
   version of Unicode that IDNA uses.


This statement would be incorrect.  The statement _does_ apply to the 
version of Unicode that IDNA uses.


-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


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

Re: 66th IETF - Registration and Hotel Accommodations

[Michael StJohns]

At 03:15 PM 4/20/2006, Pete Resnick wrote:

On 4/20/06 at 8:04 AM -0700, Ole Jacobsen wrote:

This is the first time in a long time I'm seriously considering 
*not* staying at the conference hotel. I'm not sure I see the point.


One of the sites I checked for the conference hotel indicates only 42 
non-smoking rooms at the 
hotel. 
http://english.montrealplus.ca/portal/profile.do?&profileID=558770 
Could be a problem.


Mike



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

Re: 66th IETF - Registration and Hotel Accommodations

[Pete Resnick]

On 4/20/06 at 8:04 AM -0700, Ole Jacobsen wrote:


There is at least one hotel closer to the venue also, the InterContinental.


The Delta seems to be 3 (rather long) blocks west and the 
InterContinental just across the street to the southwest.


Does anybody know the walking distances to the venue from hotels on 
the east side? I plan to vacation there the week before, and both the 
Hôtel XIXe siècle and the Hôtel Place d'Armes look charming and 
within a block or two (and I can get a decent rate).


(For the record, the Holiday Inn Select Centre-Ville seems really 
close, and relatively cheap. The St-James is also close, but now so 
cheap. :-) )


This is the first time in a long time I'm seriously considering *not* 
staying at the conference hotel. I'm not sure I see the point.


pr
--
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
QU

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

RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Tony Hain]

Brian E Carpenter wrote:
> ... 
> Scott Leibrand wrote:
> ..
>  > I agree, especially in the near term.  Aggregation is not required
> right
>  > now, but having the *ability* to aggregate later on is a prudent risk
>  > reduction strategy if today's cost to do so is minimal (as I think it
> is).
> 
> I think that's an understatement until we find an alternative to
> BGP aggregation. That's why my challenge to Iljistsch was to simulate
> 10B nodes and 100M sites - if we can't converge a reasonable sized
> table for that network, we *know* we have a big problem in our
> future. Not a risk - a certainty.
> 

The problem with your challenge is the lack of a defined topology. The
reality is that there is no consistency for topology considerations, so the
ability to construct a routing model is limited at best. 

The other point is that the protocol is irrelevant. Whatever we do the
architectural problem is finding an aggregation strategy that fits a routing
system in hardware that we know how to build, at a price point that is
economically deployable. 

As far as I am concerned BGP is not the limitation. The problem is the ego
driven myth of a single dfz where all of the gory details have to be exposed
globally. If we abolish that myth and look at the problem we are left with
an answer where BGP passing regional aggregates is sufficient. Yes there
will be exception routes that individual ISPs carry, but that is their
choice not a protocol requirement. Complaining that regional aggregates are
sub-optimal is crying wolf when they know they will eventually loose to the
money holding customer demanding non-PA space. The outcries about doom and
gloom with PI are really about random assignments which would be even less
optimal. 

The fundamental question needs to be if there is an approach to address
allocation that can be made to scale under -any- known business model, not
just the one in current practice. It is not the IETFs job to define business
models, rather to define the technology approaches that might be used and
see if the market picks up on them. Unfortunately over the last few years
the process has evolved to excluding discussions that don't fit in the
current business models, despite the continuing arguments about how those
models are financial failures and need to change. The point that Scott was
making is that there are proposals for non-random assignments which could be
carried as explicit's now and aggregated later. What we lack is a forum to
evaluate the trade-off's. 

Tony 



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

Re: 66th IETF - Registration and Hotel Accommodations

[Ole Jacobsen]

There is at least one hotel closer to the venue also, the 
InterContinental.

Ole



Ole J. Jacobsen 
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: [EMAIL PROTECTED]  URL: http://www.cisco.com/ipj



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

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Brian E Carpenter]

Kevin Loch wrote:
...

In case you (IETF) diddn't get the memo, the operational community has
flat out rejected shim6 in it's current form as a replacement
for PI.


Kevin, I realise you may have felt provoked by the tone of
some earlier messages, but I must point out that (a) the shim6
work is only at the stage of WG discussion, so "reject" is
really not relevant at this point, and (b) I know personally
of people in the operational community who, far from rejecting
it, are actively working on the specifications.

That being said, constructive technical input from the operational
community is very welcome and is always listened to. Shim6 *is*
listening to it.


This failure of leadership from the IETF to provide a roadmap for a
viable alternative to PI is a factor in the support for going with
the current technology.


First of all, "the IETF" is the set of people who choose to work
in the IETF. So if there is a failure, all of us here should look
in the mirror together to find the culprits. Second, I believe that
the failure is much deeper, at the mathematical level - we need an
alternative to the BGP4 model we've been based on for ten years,
and that is a truly hard problem.

Scott Leibrand wrote:
..
> I agree, especially in the near term.  Aggregation is not required right
> now, but having the *ability* to aggregate later on is a prudent risk
> reduction strategy if today's cost to do so is minimal (as I think it is).

I think that's an understatement until we find an alternative to
BGP aggregation. That's why my challenge to Iljistsch was to simulate
10B nodes and 100M sites - if we can't converge a reasonable sized
table for that network, we *know* we have a big problem in our
future. Not a risk - a certainty.

Edward Lewis wrote:
...
>
> The debate between 1) what happens to router tables with PI prefixes, 2)
> what happens when the protocol is crimped into a comfortable-to-operate
> fashion, and 3) what customers are will to bear, has been raging for
> more than a year.
>
> It's plain to see that PI space threatens to blow up routing.
> It's plain to see that IPv6 is supposed to allow for end-to-end
> flexibility.
> It's plain to see that customers no longer want to be tied to ISPs.

With all due respect to the debates in the RIRs, these three facts were
well known when the multi6 WG was created, four years before the
shim6 proposals emerged. Also, I refer you to a recent message in a
forked part of this thread:
http://ops.ietf.org/lists/shim6/msg01288.html
in which Scott Leibrand nicely positions shim6 and PI as parts of
the overall solution space.

 Brian

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

Merging PIDF documents from multiple sources

[Tor Noga]

Title: Merging PIDF documents from multiple sources






Hi 

Im trying to understand what should be the strategy when merging doucments that were published from different sources.

Should all published person\tuple\device elements be sent to the Watcher as received?

Or should a merge strategy be implemented? 

For example: 

PUBLISH1







    ….





    ….





    ….





    ….





PUBLISH2







    ….





    ….





    ….





    ….





How should the Notify message look like? (assuming the watcher did not add any filters to the subscription)

Should it contain all the published elements? (like following example)

Or should it contain merged publish elements? (one person/device element)

Or should it contain just the last published elements? (one person/device element)


NOTIFY1







    ….





    ….





    ….





    ….





    ….





    ….





    ….





    ….






Thanks

Noga Tor



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

Re: Impending publication: draft-iab-idn-nextsteps-05

[Simon Josefsson]

In general, I think some of the specific recommendations in section 4
are poorly researched.  I think it is bad advice to even suggest
people to look into the solution outlined in section 4.3.  It seems to
me that adopting the approach would break backwards compatibility in
Unicode for most European languages, which would be a serious problem.

2.2.8.  Versions of Unicode
...
   An example of the type of change that appears to be just a small
   correction from one perspective but may be problematic from another
   was the correction to the normalization definition in 2004 [Unicode-
   PR29].

I believe it should be noted here that this was discovered after
Unicode 3.2 was published, and consequently doesn't apply to the
original Unicode 3.2.  I.e., change 'PR29].' into:

   PR29], which was discovered after Unicode 3.2 was published.

Further:

   There was community input that the change would cause problems for
   Stringprep, but UTC decided, on balance, that the change was
   worthwhile.  Because of difficulties with consistency, some
   deployed implementations have decided to adopt the change and
   others have not, leading to subtle incompatibilities.

Similarly, here it would be useful that some IDNA implementers have
adopted the fix despite that it doesn't apply to Unicode 3.2, and that
IDNA reference Unicode 3.2 explicitly.  The subtle incompatibilities
are not the direct result of Unicode Consortium's actions, but the
choice made by some implementers.

For the record, my implementation, Libidn, implement the original
Unicode 3.2 semantics.

I suggest replacing 'incompatibilities.' with:

   incompatibilities, despite that the change does not apply to the
   version of Unicode that IDNA uses.

Thanks.

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

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Kevin Loch]

Peter Sherbin wrote:


This is a proper model which should remain this way with a little fix. IETF
engineering effort is funded (indirectly) by the employers of the engineers. 
RIRs
administrative work is funded through membership and allocation fees, which
essentially equals selling of IP addresses. Because the Internet is a shared
resourse its enablers such as IP addresses are not for sale but rather for a 
free
assignment to everyone. RIRs function should be funded through a politically /
economically neutral body, e.g. UN. Technically the current way of RIR cost 
recovery
hinders the network neutrality.


I wouldn't consider any policital body, especially the UN to be
politically (and thus economically) neutral.  I also don't see how RIR
fees affect policy in any way.  At least in ARIN, anyone is allowed to
participate in the policy process regardless of resources delegated or
fees paid.

- Kevin

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

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Erik E. Fair]

I'm patient, but when you have a heavily loaded VAX-11/780 (I think
this was before the host apple.com was upgraded to a VAX-8650)
doing netnews, where even the highly optimized "compress" program
beats on the CPU, and a Cray X/MP-48 just sitting there across the
LAN ...

So, I set up a TCP "compression service" set up on the Cray (bits
go in, compressed bits come out; inetd makes this easy and UniCOS
came with the "compress") and blasted netnews batches across the
10Mb/s Ethernet from the VAX and captured the results for transmission
to Apple's UUCP-based netnews neighbors.

It was lots faster that way and it took a large load off the VAX.
Unfortunately, I had to discontinue the practice when some of my
netnews neighbors complained of corrupted batches; it seems that
there were some subtle 32 bit assumptions in compress that I didn't
have the time to track down. Still, it was fun to play with a
supercomputer at a place where they believed in interactive computing,
and didn't charge for CPU time.

Then there was the time I ported pathalias to the Cray ...

Erik <[EMAIL PROTECTED]>

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

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Peter Sherbin]

Hi,

> Things work a lot better if IETF and RIRs work hand-in-hand - that is,
> IETF makes standards that people can work with, and RIRs use allocation
> policies that somewhat reflect what the protocol designers had in mind.

This is a proper model which should remain this way with a little fix. IETF
engineering effort is funded (indirectly) by the employers of the engineers. 
RIRs
administrative work is funded through membership and allocation fees, which
essentially equals selling of IP addresses. Because the Internet is a shared
resourse its enablers such as IP addresses are not for sale but rather for a 
free
assignment to everyone. RIRs function should be funded through a politically /
economically neutral body, e.g. UN. Technically the current way of RIR cost 
recovery
hinders the network neutrality.

Peter


--- Gert Doering <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote:
> > The IETF has NOTHING to say anymore than any other body about any RIR
> > policy. I want it to remain that way.  IETF job is a standards body not
> > a deployment body.
> 
> Things work a lot better if IETF and RIRs work hand-in-hand - that is,
> IETF makes standards that people can work with, and RIRs use allocation
> policies that somewhat reflect what the protocol designers had in mind.
> 
> For IPv6, this isn't a huge success story yet...
> 
> Gert Doering
> -- NetMaster
> -- 
> Total number of prefixes smaller than registry allocations:  88685
> 
> SpaceNet AGMail: [EMAIL PROTECTED]
> Joseph-Dollinger-Bogen 14  Tel : +49-89-32356-0
> D- 80807 Muenchen  Fax : +49-89-32356-234
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: 66th IETF - Registration and Hotel Accommodations

[Brian E Carpenter]

Tim Chown wrote:

On Wed, Apr 19, 2006 at 06:07:50PM -0500, Spencer Dawkins wrote:

Thanks to IAD for opening registration (helps with visa requests, although 
this is less of a problem in Canada than "elsewhere in North America").



Yes, very nice to have the hotel and registration open 3 month in advance
this time, well done!

I called direct, got a booking and a confirmation PDF by email, very easy.

But note the hotel is not the meeting venue as far as I can tell.  Some 
info on distances involved (or even a map showing locations) would be 
helpful.  Using zip codes on www.multimap.com (H3C 3Z7 for the hotel and

H2Z 1H2 for the Palais) suggests it's a couple of blocks along a fairly
major road, which should be easy walking distance...


It's said to be a short walk (quite different from IETF 36, which was
held in the same conference centre, but with the main hotel several
metro stops away).

Brian


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

Re: 66th IETF - Registration and Hotel Accommodations

[Tim Chown]

On Wed, Apr 19, 2006 at 06:07:50PM -0500, Spencer Dawkins wrote:
> 
> Thanks to IAD for opening registration (helps with visa requests, although 
> this is less of a problem in Canada than "elsewhere in North America").

Yes, very nice to have the hotel and registration open 3 month in advance
this time, well done!

I called direct, got a booking and a confirmation PDF by email, very easy.

But note the hotel is not the meeting venue as far as I can tell.  Some 
info on distances involved (or even a map showing locations) would be 
helpful.  Using zip codes on www.multimap.com (H3C 3Z7 for the hotel and
H2Z 1H2 for the Palais) suggests it's a couple of blocks along a fairly
major road, which should be easy walking distance...

-- 
Tim/::1

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