Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[Peter Koch]

>  IPv6 Support Required for all IP-capable nodes
>   draft-ietf-intarea-ipv6-required-01

The document strives to convey the message that "IP" is no longer
equivalent to "IPv4", which is a goal that I'd fully support.
However, while this is a political statement that the IETF really should
make, i have a large amount of scepticism that the document, as
it is written, can successfully convey the message to the desired
target audience.

For one, i share the concerns raised by others that "updating" various
old RFCs is not the right way to go.  First, the documents technically
are not in need of an update (e.g., because RFC 1812 pretty clearly
states that it deals with v4 routers only). Second, changing sentences
or phrases in existing documents, although not without precedent, isn't
best IETF style. This is especially dubious w.r.t. RFC 4084, BCP 104.

Most importantly, though, the updates to existing documents are so
sophisticated and so highly likely to be overread that I'd not see
anybody who managed to remain unaware until today to now follow suit.
It feels a bit like giving purchase departments, or maybe even
legal departments a lever to defeat claims that a product is "IP capable"
when it indeed is IPv4 only.

In that context, these two statements

>   New IP implementations MUST support IPv6.
>
>   Current IP implementations SHOULD support IPv6.

appear especially interesting. What divides implementations into "new"
and "current" and what's the purpose of stating requirements for
"current" implementations, assuming an intuitive meaning of the word?

I'd agree the IETF (and other I* bodies) have a point in making
strong statements about IPv6 adoption, but the IETF has traditionally
abstained from addressing individual false claims of "RFC compliance".
To that extent i do not see how this would be different for the draft
in Last Call.  For the really agnostic, it also isn't too helpful
since RFCs 1812 and 1122 are of lesser concern.  Documents like RIPE-501,
although not ideal, provide much better guidance.

In summary, if the core message is "IP != IPv4" then i believe the
text isn't crisp enough; if it were bullets for legal/purchase, i do not
see the point.

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

Re: Experiment for different schedule for Friday

[John C Klensin]

+1.  I could also happily live with the alternate, more
compressed, schedule -- I think both are preferable to the
schedule used in Quebec and earlier.

   john


--On Tuesday, August 23, 2011 07:40 +0200 Eliot Lear
 wrote:

> 
> 
> On 8/22/11 11:24 PM, IETF Chair wrote:
>> The IESG is considering a different schedule for the Friday
>> of IETF 82.  The IESG is seeking your input on these
>> potential changes.
>> 
>> The IESG would like to try a schedule experiment on Friday,
>> using this schedule:
>> 
>>  9:00 AM - 11:00 AM - Session I
>> 11:00 AM - 11:20 AM - Room Change and Cookie Break
>> 11:20 AM - 12:20 PM - Session II
>> 12:10 PM - 12:30 PM - Room Change Break
>> 12:30 PM - 13:30 PM - Session III
>> 
>> The IESG has already consulted with the IAOC because of the
>> cost associated with the additional food and beverage break.
>> The IAOC believes that the additional cost can be managed
>> without raising the meeting fee.
> 
> I think this is a good experiment to run as proposed.




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

Re: Experiment for different schedule for Friday

[Eliot Lear]

On 8/22/11 11:24 PM, IETF Chair wrote:
> The IESG is considering a different schedule for the Friday of IETF 82.  The 
> IESG is seeking your input on these potential changes.
>
> The IESG would like to try a schedule experiment on Friday, using this 
> schedule:
>
>  9:00 AM - 11:00 AM - Session I
> 11:00 AM - 11:20 AM - Room Change and Cookie Break
> 11:20 AM - 12:20 PM - Session II
> 12:10 PM - 12:30 PM - Room Change Break
> 12:30 PM - 13:30 PM - Session III
>
> The IESG has already consulted with the IAOC because of the cost associated 
> with the additional food and beverage break.  The IAOC believes that the 
> additional cost can be managed without raising the meeting fee.

I think this is a good experiment to run as proposed.

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

Re: Hyatt Taipei cancellation policy?

[John C Klensin]

--On Monday, August 22, 2011 20:16 -0400 Ray Pelletier
 wrote:

>...
> As for the rates, they are high.  Taiwan is expensive,
> particularly given that the hotels know what our options are
> when we book the TICC.  The Hyatt knew that foreign visitors
> needed to use the Hyatt as headquarters and charged
> accordingly.  Since the time of our site visit, 2 new hotels
> have been constructed in the vicinity of the TICC (Le Meridien
> and W), which may provide more competition for Hyatt in these
> circumstances.  At the time we were working on this event,
> there were no acceptable options.

Ray,

I know you want to find sponsors and go where the sponsors want
to go.  I accept the explanation that you negotiated as hard as
you could for both room rates and cancellation policies.  But I
have to wonder, especially in the light of Lixia's observation
about the US Govt rate (which, internationally, is often a
pretty good measure for the higher end of a reasonable rate in a
given city), whether there is a stopping rule.  We were told in
Quebec that you had given up on one Southeast Asian city because
rooms would have cost over USD 300 a night. I don't remember
hearing about a sponsor there.  What looks like USD 275 net is
not all that much less than USD 300, especially if the dollar
continues to sink.

So, if you had a sponsor for a future meeting at that other
location, would an estimated USD 300 be acceptable?  USD 350?

I obviously don't have all of the information available to me
that you and the IAOC do, but it seems to be there is always
another alternative.   If there are no local ones, that
alternative is usually described as "just say no and go
elsewhere".  What I'm trying to understand, mostly for the
future and with the understanding that it is presumably much too
late for Taipei and the several following meetings, is whether
you would ever consider that an option for a meeting for which
you have a sponsor if you hold it in a particular place or if
you and the IAOC really believe there is no alternative under
those circumstances.

   john


   john


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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

[SM]

At 14:56 22-08-2011, Chris Donley wrote:

This proposal reached ARIN consensus (2011-5), and has been recommended
for adoption to the ARIN board. The ARIN BoD has indicated that it is
willing to reserve a /10 if asked to do so by the IETF/IANA.

[snip]

This will be supplied by IANA in consultation with ARIN.  ARIN has not
pre-announced what block might be used, so we need to wait until IANA gets
back to us later in the process.


The information could have been mentioned as a note in the draft.


Not quite right. We first brought this proposal to OPSAWG in Maastricht,
and then updated it for Beijing.  From the opsawg (79) minutes:
> Straw poll: more people in the room supported the draft than didn't,
> perhaps 2:1. About half the room expressed an opinion.

Because IANA was down to its final /8, we were asked to also present in
v6ops, which did not reach consensus for or against. Feedback from v6ops
was to approach the RIRs for space, rather than IANA, which we did.


And a RIR sent this back to the IETF.


How is this relevant? Jason, Victor, and I have been working on this for
over a year.  Chris L and Marla joined the author team with significant
contributions when we substantially updated the draft prior to IETF79.


That was an editorial nit.  Without the above explanation, it comes 
through as a case of corporate name-dropping.


Regards,
-sm 


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

Re: Hyatt Taipei cancellation policy?

[Michael StJohns]

At 08:30 PM 8/22/2011, Marshall Eubanks wrote:
>Guest Substitution: Guests may substitute names for reserved rooms without 
>penalty up to the event.
>
>
>This sounds like a good use of the Attendees list. Anyone with reservations 
>who can't come should publicize it - I am sure that there will be  people who 
>want to come but can't get reservations.


Sorry Marshall - you're mostly trying to solve a different problem.  For 
Hiroshima, I literally decided not to come at the last minute. And my scheduled 
travel was such that I was able to cancel prior to 24 hours so I didn't even 
incur the 1 day fee.  

Anyone going to Taipei is pretty much going to have everything scheduled prior 
to 24 hours before arrival (or maybe risk sleeping on the street or 10 miles 
away).  The chance of being able to find someone to take your reservation with 
less than 72 hours to go is pretty slim - especially considering the other 
hotel in the block also requires 72 hour notice to cancel.

Later, Mike



>Regards
>Marshall

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

Re: Hyatt Taipei cancellation policy?

[Michael StJohns]

Hi Ray - 

See below

At 08:15 PM 8/22/2011, Ray Pelletier wrote:

>On Aug 22, 2011, at 3:17 PM, Michael StJohns wrote:
>
>> Hi folks - 
>> 
>> I just reserved with the hotel and was quite surprised at the cancellation 
>> policy.
>> 
>> Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1 night, 
>> after 7 Nov full amount?
>
>As stated on the meeting site:  
>
>Guest Cancellation: Individuals may cancel reservations without penalty until 
>7 days prior to scheduled check-in/arrival. In case of cancellation between 3 
>and 7 days prior to scheduled check-in/arrival, the Hotel holds the right to 
>charge the individuals one night’s stay as a cancellation fee. In case of 
>cancellation less than 3 days prior to the scheduled check-in/arrival or 
>non-arrival or no-show, the Hotel holds the right to charge the individuals 
>for the entire scheduled stay as a cancellation fee.


The policy stated on the hotel web site (to which I had to agree to get the 
reservation)  was Nov 1-7 1 day, after Nov 7 - full amount.  Obviously a 
disconnect.



>We strive at each meeting to get the best cancellation policies that we can, 
>looking for a 1 day cancellation penalty for a cancellation.  Often, in Asia 
>and Europe in particular, they will not agree to this. We did negotiate this 
>pretty heavily to get the terms we now have.  Originally, the hotel wanted to 
>the entire stay to be charged for cancellation or no-show at the cut-off date 
>(26 October).  

Could you refresh my memory as to which hotels we stayed at had this policy?  I 
literally cannot remember having any hotel cancellation policy with more than a 
single night fee ever.  

I will point out there are at least two hotels in walking distance with only 
slightly more expensive rack rates that have only a 1 night fee if you don't 
cancel at least 24 hours in advance.  It may be useful to have the hotel 
re-address the cancellation fee issue in light of that.

Thanks - Mike




>While this may only a solution for some, names may be substituted without 
>penalty up to the event.
>
>Guest Substitution: Guests may substitute names for reserved rooms without 
>penalty up to the event.
>
>Ray
>
>> 
>> Seriously?  This is extreme. I can understand a 1 day fee up to the date of 
>> the reservation and maybe even charging the full amount if I don't cancel, 
>> but paying $1500+ because I had to cancel at the last moment seems a bit 
>> confiscatory.  
>> 
>> Mike
>> 
>> ___
>> 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: Alternative to the Hyatt

[Dave CROCKER]

Clarification:

The special rate is listed as the Early Bird Package on the website.  That part 
/is/ available.  It's the actual booking that doesn't seem to handle it.


d/

On 8/22/2011 5:29 PM, Dave CROCKER wrote:

For reference, I found the AT Boutique Hotel, near the Convention Center.

Tripadvisor comments are generally positive and the facilities are claimed to be
newish. Photos look fine. Modest, workable place. Breakfast and wifi included.

Prices are entirely reasonable, although of course you get a small room.

They have a book-ahead special that doesn't seem to be available through the
online system. I got it by faxing the hotel. It gives you the windowless rate
for a room with a window...


--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call:

[Frank Ellermann]

Am 2011-08-23 01:03, schrieb Brian E Carpenter:


Nothing is wrong in BCP 104, it needs no "updated by" moving the definition
of the term "version support" from one of its sections to another section.



But there *is* something wrong with it - it makes IPv6 sound
like an optional add-on to basic IP service.



I thought this was a bug in BCP 104 at the time, and told the
author so, but lost that argument. That was reasonable in
2004/5, but things have moved on. Then, an ISP could argue that
providing IPv6 service was difficult or impossible; today, that
excuse is weak.


This is a very important BCP.  It is about non-Internet providers
claiming to be ISPs while favouring packets by IP or manipulating
DNS.  Not offering IPv6 in 2011 also isn't nice, but if the latter
requires new text it should be in a new BCP.  While at it the new
BCP could reference 4409bis instead of RFC 2476.

Getting an "updated by" only as some kind of IPv6 promotion would
IMHO not help with the main purpose of this BCP.

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

Re: Hyatt Taipei cancellation policy?

[Marshall Eubanks]

On Mon, Aug 22, 2011 at 8:15 PM, Ray Pelletier  wrote:

>
> On Aug 22, 2011, at 3:17 PM, Michael StJohns wrote:
>
> > Hi folks -
> >
> > I just reserved with the hotel and was quite surprised at the
> cancellation policy.
> >
> > Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1
> night, after 7 Nov full amount?
>
> As stated on the meeting site:   >
>
> Guest Cancellation: Individuals may cancel reservations without penalty
> until 7 days prior to scheduled check-in/arrival. In case of cancellation
> between 3 and 7 days prior to scheduled check-in/arrival, the Hotel holds
> the right to charge the individuals one night’s stay as a cancellation fee.
> In case of cancellation less than 3 days prior to the scheduled
> check-in/arrival or non-arrival or no-show, the Hotel holds the right to
> charge the individuals for the entire scheduled stay as a cancellation fee.
>
> We strive at each meeting to get the best cancellation policies that we
> can, looking for a 1 day cancellation penalty for a cancellation.  Often, in
> Asia and Europe in particular, they will not agree to this. We did negotiate
> this pretty heavily to get the terms we now have.  Originally, the hotel
> wanted to the entire stay to be charged for cancellation or no-show at the
> cut-off date (26 October).
>
> While this may only a solution for some, names may be substituted without
> penalty up to the event.
>
> Guest Substitution: Guests may substitute names for reserved rooms without
> penalty up to the event.
>
>
This sounds like a good use of the Attendees list. Anyone with reservations
who can't come should publicize it - I am sure that there will be  people
who want to come but can't get reservations.

Regards
Marshall


> Ray
>
> >
> > Seriously?  This is extreme. I can understand a 1 day fee up to the date
> of the reservation and maybe even charging the full amount if I don't
> cancel, but paying $1500+ because I had to cancel at the last moment seems a
> bit confiscatory.
> >
> > Mike
> >
> > ___
> > 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
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Alternative to the Hyatt

[Dave CROCKER]

On 8/22/2011 5:16 PM, Ray Pelletier wrote:

The Hyatt knew that foreign visitors needed to use the Hyatt as headquarters



Folks,

For reference, I found the AT Boutique Hotel, near the Convention Center.

Tripadvisor comments are generally positive and the facilities are claimed to be 
newish.  Photos look fine.  Modest, workable place. Breakfast and wifi included.


Prices are entirely reasonable, although of course you get a small room.

They have a book-ahead special that doesn't seem to be available through the 
online system.  I got it by faxing the hotel.  It gives you the windowless rate 
for a room with a window...


The Hyatt is a bit northeast of the Center.  The Boutique is a bit southwest.

d/

ps. They have a page in English, and the fellow responding with a fax produced 
easy English, but it's clear this hotel is not targeted for English speakers. 
My usual experience at such places is that there is enough

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Hyatt Taipei cancellation policy?

[Ray Pelletier]

On Aug 22, 2011, at 3:53 PM, Lixia Zhang wrote:

> 
> Since you brought up the subject of hotel: up to now IETF hotel prices have 
> been within the federal per diem allowance, but IETF82 seems an exception by 
> a pretty big gap (see 
> http://aoprals.state.gov/web920/per_diem_action.asp?MenuHide=1&CountryCode=1142,
>  lodging allowance $186/day, a single room at Hyatt is $263/day with 10% tax)

As for the rates, they are high.  Taiwan is expensive, particularly given that 
the hotels know what our options are when we book the TICC.  The Hyatt knew 
that foreign visitors needed to use the Hyatt as headquarters and charged 
accordingly.  Since the time of our site visit, 2 new hotels have been 
constructed in the vicinity of the TICC (Le Meridien and W), which may provide 
more competition for Hyatt in these circumstances.  At the time we were working 
on this event, there were no acceptable options.

Ray

> 
> 
> ___
> 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: Hyatt Taipei cancellation policy?

[Ray Pelletier]

On Aug 22, 2011, at 3:17 PM, Michael StJohns wrote:

> Hi folks - 
> 
> I just reserved with the hotel and was quite surprised at the cancellation 
> policy.
> 
> Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1 night, 
> after 7 Nov full amount?

As stated on the meeting site:  

Guest Cancellation: Individuals may cancel reservations without penalty until 7 
days prior to scheduled check-in/arrival. In case of cancellation between 3 and 
7 days prior to scheduled check-in/arrival, the Hotel holds the right to charge 
the individuals one night’s stay as a cancellation fee. In case of cancellation 
less than 3 days prior to the scheduled check-in/arrival or non-arrival or 
no-show, the Hotel holds the right to charge the individuals for the entire 
scheduled stay as a cancellation fee.

We strive at each meeting to get the best cancellation policies that we can, 
looking for a 1 day cancellation penalty for a cancellation.  Often, in Asia 
and Europe in particular, they will not agree to this. We did negotiate this 
pretty heavily to get the terms we now have.  Originally, the hotel wanted to 
the entire stay to be charged for cancellation or no-show at the cut-off date 
(26 October).  

While this may only a solution for some, names may be substituted without 
penalty up to the event.

Guest Substitution: Guests may substitute names for reserved rooms without 
penalty up to the event.

Ray

> 
> Seriously?  This is extreme. I can understand a 1 day fee up to the date of 
> the reservation and maybe even charging the full amount if I don't cancel, 
> but paying $1500+ because I had to cancel at the last moment seems a bit 
> confiscatory.  
> 
> Mike
> 
> ___
> 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] Re: Experiment for different schedule for Friday

[Warren Kumari]

On Aug 22, 2011, at 7:28 PM, Randall Gellens wrote:

> At 5:24 PM -0400 8/22/11, IETF Chair wrote:
> 
>> The IESG is considering a different schedule for the Friday of IETF 82.  The 
>> IESG is seeking your input on these potential changes.
>> 
>> The IESG would like to try a schedule experiment on Friday, using this 
>> schedule:
>> 
>>  9:00 AM - 11:00 AM - Session I
>> 11:00 AM - 11:20 AM - Room Change and Cookie Break
>> 11:20 AM - 12:20 PM - Session II
>> 12:10 PM - 12:30 PM - Room Change Break
>> 12:30 PM - 13:30 PM - Session III
> 
> I'd suggest shortening the first session and eliminating the cookie break, so:
> 
> 9:00 AM - 10:30 AM: Session I
> 10:30 AM - 10:40 AM: room change
> 10:40 AM - 11:40 AM: Session II
> 11:40 AM - 11:50 AM: room change
> 11:50 AM - 12:50 PM: Session III
> 
> I don't think 20 minutes is sufficient for a cookie break and room change, 
> and think we can go without in order to be done sooner. However, if people 
> really want cookies, perhaps they could be in the meeting rooms during 
> Session II instead of centrally?

Or perhaps they could plan ahead a little and grab a cookie or two (and some 
coffee) before the meeting….

W


> 
> -- 
> Randall Gellens
> Opinions are personal;facts are suspect;I speak for myself only
> -- Randomly selected tag: ---
> If you can't annoy somebody there's little point in writing --Kingsley Amis
> ___
> 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: Experiment for different schedule for Friday

[Randall Gellens]

At 5:24 PM -0400 8/22/11, IETF Chair wrote:

 The IESG is considering a different schedule for the Friday of IETF 
82.  The IESG is seeking your input on these potential changes.


 The IESG would like to try a schedule experiment on Friday, using 
this schedule:


  9:00 AM - 11:00 AM - Session I
 11:00 AM - 11:20 AM - Room Change and Cookie Break
 11:20 AM - 12:20 PM - Session II
 12:10 PM - 12:30 PM - Room Change Break
 12:30 PM - 13:30 PM - Session III


I'd suggest shortening the first session and eliminating the cookie break, so:

 9:00 AM - 10:30 AM: Session I
10:30 AM - 10:40 AM: room change
10:40 AM - 11:40 AM: Session II
11:40 AM - 11:50 AM: room change
11:50 AM - 12:50 PM: Session III

I don't think 20 minutes is sufficient for a cookie break and room 
change, and think we can go without in order to be done sooner. 
However, if people really want cookies, perhaps they could be in the 
meeting rooms during Session II instead of centrally?


--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly selected tag: ---
If you can't annoy somebody there's little point in writing --Kingsley Amis
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call:

[Brian E Carpenter]

Frank,

On 2011-08-23 00:09, Frank Ellermann wrote:
> Nothing is wrong in BCP 104, it needs no "updated by" moving the definition
> of the term "version support" from one of its sections to another section.

But there *is* something wrong with it - it makes IPv6 sound
like an optional add-on to basic IP service.

I thought this was a bug in BCP 104 at the time, and told the
author so, but lost that argument. That was reasonable in
2004/5, but things have moved on. Then, an ISP could argue that
providing IPv6 service was difficult or impossible; today, that
excuse is weak.

On 2011-08-23 07:44, George, Wesley wrote:

> Brian was the one who originally suggested this RFC be added as updated by 
> this draft, so I'm keen to hear his opinion as well.

Well, I'm not sure there is much point in wordsmithing BCP 104
beyond simply moving version support up into first class, but I
am completely convinced that should be done.

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

Re: Experiment for different schedule for Friday

[James M. Polk]

At 04:24 PM 8/22/2011, IETF Chair wrote:
The IESG is considering a different schedule for the Friday of IETF 
82.  The IESG is seeking your input on these potential changes.


The IESG would like to try a schedule experiment on Friday, using 
this schedule:


 9:00 AM - 11:00 AM - Session I
11:00 AM - 11:20 AM - Room Change and Cookie Break
11:20 AM - 12:20 PM - Session II
12:10 PM - 12:30 PM - Room Change Break
12:30 PM - 13:30 PM - Session III


since there will be cookies, this is ok with me  ;-)


The IESG has already consulted with the IAOC because of the cost 
associated with the additional food and beverage break.  The IAOC 
believes that the additional cost can be managed without raising the 
meeting fee.


bonus

James



On behalf of the IESG,
   Russ
___
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: (IPv6Support Required for all IP-capable nodes) to Proposed Standard

[Brian E Carpenter]

+1 to Ned. I can't see why this draft seems to make some people
go defensive - it isn't saying "IPv4 is evil" or anything silly
like that, it's just saying "IPv6 is the future".

RFC1122v6 is another matter entirely. We clearly aren't ready
for it yet, but draft-ietf-6man-node-req-bis is a step on the way.

Regards
   Brian

On 2011-08-23 08:54, ned+i...@mauve.mrochek.com wrote:
>> I find this document utterly bizarre and think it would seriously damage the
>> Internet to publish it.
> 
> This seems a little ... extreme. The document appears to me to be Mostly
> Harmless, with all that implies.
> 
>> The idea that ipv6 should be regarded as normal, as of equal standing to 
>> ipv4 is
>> fine, the sort of statement that the IAB should make, or have made, as an 
>> RFC or
>> in some other form.
> 
>> But this I-D claims
>> " Updates [RFC1122] to clarify that this document, especially in
>>section 3, primarily discusses IPv4 where it uses the more generic
>>term "IP" and is no longer a complete definition of "IP" or the
>>Internet Protocol suite by itself.  "
> 
>> IPv4 is a phenomenal success, and RFC1122 is a key part of that.  IPv4 was a
>> confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, 
>> cut
>> through the cruft and rendered it usable.  IPv6 desparately needs an 
>> equivalent
>> to RFC1122,
> 
> Complete agreement on this point. Such a document, informed by actual IPv6
> deployment experience at some sort of scale, is urgently needed. And this most
> certainly is NOT that document. But unless publishing this is seen as meeting
> the need for an 1122v6 - and I've seen no indication that's the case - I fail
> to see the harm.
> 
> OTOH, if this really is seen as being a 1122v6, then I join you in opposing
> it's publication.
> 
>> as a trawl of the v6ops list archives shows, and clearly this I-D is
>> never going to be it, but claiming that this I-D provides an update to 
>> RFC1122,
>> coupled
>> with its title, gives the message that there is not going to be such an I-D;
>> IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
>> success of IPv4).
> 
> Maybe I'm being clueless about this, but I don't see how "IPv6 Support 
> Required
> for all IP-capable nodes" gives this impression.
> 
>   Ned
> ___
> 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: (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

[Chris Donley]

On 8/19/11 3:42 PM, "SM"  wrote:

>At 09:10 19-08-2011, The IESG wrote:
>>The IESG has received a request from an individual submitter to consider
>>the following document:
>>- 'IANA Reserved IPv4 Prefix for Shared Transition Space'
>>as an
>>Informational
>>RFC
>>
>>The IESG plans to make a decision in the next few weeks, and solicits
>>final comments on this action. Please send substantive comments to the
>>ietf@ietf.org mailing lists by 2011-09-16. Exceptionally, comments may be
>
>
>The draft only mentions an applicability and justification for Shared
>Transition Space and references
>draft-bdgks-arin-shared-transition-space-00.  While the policy fits
>under RIR community processes, it does not fit under allocations made
>for technical specifications.  Publishing this document on the
>grounds that the ARIN wants it is not a good enough reason.  Will
>ARIN be "donating" the /10 IPv4 address space to IANA for it to make
>this allocation?
This proposal reached ARIN consensus (2011-5), and has been recommended
for adoption to the ARIN board. The ARIN BoD has indicated that it is
willing to reserve a /10 if asked to do so by the IETF/IANA.


>
>The draft mentions that:
>
>   "Network equipment manufacturers MUST NOT use the
>assigned block in default or example device configurations."
>
>As the IPv4 address block is not specified in the document, the above
>requirement cannot be followed.  The expectation that the IPv4
>address block will only be used by Infrastructure Providers is
>optimistic.  
This will be supplied by IANA in consultation with ARIN.  ARIN has not
pre-announced what block might be used, so we need to wait until IANA gets
back to us later in the process.

>RFC 5735 covers Special Use IPv4 Addresses.  This
>document should update the BCP.
Once we get an assignment from IANA/ARIN, we'll look into updating RFC
5735.
>
>A proposal similar to this one was discussed in a V6OPS meeting in
>Asia.  If my reading is correct, it did not gain consensus.  The
>proposal gets discussed in North America in
>OPSAWG and it gains consensus.
Not quite right. We first brought this proposal to OPSAWG in Maastricht,
and then updated it for Beijing.  From the opsawg (79) minutes:
> Straw poll: more people in the room supported the draft than didn't,
> perhaps 2:1. About half the room expressed an opinion.

Because IANA was down to its final /8, we were asked to also present in
v6ops, which did not reach consensus for or against. Feedback from v6ops
was to approach the RIRs for space, rather than IANA, which we did.

> BTW, this draft contains only 220
>lines, including boilerplate and it has five authors.
How is this relevant? Jason, Victor, and I have been working on this for
over a year.  Chris L and Marla joined the author team with significant
contributions when we substantially updated the draft prior to IETF79.

Chris
>
>Regards,
>-sm 
>
>___
>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

Experiment for different schedule for Friday

[IETF Chair]

The IESG is considering a different schedule for the Friday of IETF 82.  The 
IESG is seeking your input on these potential changes.

The IESG would like to try a schedule experiment on Friday, using this schedule:

 9:00 AM - 11:00 AM - Session I
11:00 AM - 11:20 AM - Room Change and Cookie Break
11:20 AM - 12:20 PM - Session II
12:10 PM - 12:30 PM - Room Change Break
12:30 PM - 13:30 PM - Session III

The IESG has already consulted with the IAOC because of the cost associated 
with the additional food and beverage break.  The IAOC believes that the 
additional cost can be managed without raising the meeting fee.

On behalf of the IESG,
   Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IPv6Support Required for all IP-capable nodes) to Proposed Standard

[ned+ietf]

> I find this document utterly bizarre and think it would seriously damage the
> Internet to publish it.

This seems a little ... extreme. The document appears to me to be Mostly
Harmless, with all that implies.

> The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 
> is
> fine, the sort of statement that the IAB should make, or have made, as an RFC 
> or
> in some other form.

> But this I-D claims
> " Updates [RFC1122] to clarify that this document, especially in
>section 3, primarily discusses IPv4 where it uses the more generic
>term "IP" and is no longer a complete definition of "IP" or the
>Internet Protocol suite by itself.  "

> IPv4 is a phenomenal success, and RFC1122 is a key part of that.  IPv4 was a
> confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
> through the cruft and rendered it usable.  IPv6 desparately needs an 
> equivalent
> to RFC1122,

Complete agreement on this point. Such a document, informed by actual IPv6
deployment experience at some sort of scale, is urgently needed. And this most
certainly is NOT that document. But unless publishing this is seen as meeting
the need for an 1122v6 - and I've seen no indication that's the case - I fail
to see the harm.

OTOH, if this really is seen as being a 1122v6, then I join you in opposing
it's publication.

> as a trawl of the v6ops list archives shows, and clearly this I-D is
> never going to be it, but claiming that this I-D provides an update to 
> RFC1122,
> coupled
> with its title, gives the message that there is not going to be such an I-D;
> IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
> success of IPv4).

Maybe I'm being clueless about this, but I don't see how "IPv6 Support Required
for all IP-capable nodes" gives this impression.

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

Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[SM]

Hi George,
At 10:11 22-08-2011, George, Wesley wrote:
WEG] You're reading too much into this. It's a statement of the 
current situation, not a discussion about whether unique addresses 
are good or bad.


Ok.

WEG] As an operator (consumer ISP) who happens to spend a lot of 
time talking about IPv6 deployments with other operators, I disagree 
with this assertion. This is exactly the problem we're trying to 
solve. From where I sit, I see credible plans from a number of US 
residential broadband providers to have IPv6 enabled on a large 
portion of their
 footprint within the next 12-18 months. There is no reason why 
IPv6 support in ancillary


From where I sit I have not seen credible plans from residential 
broadband providers to have IPv6 enabled.  Please note that my 
comment should not be read as a disagreement about what you said 
about US residential providers.


 devices needs to be a serial process dependent on completion of 
that last mile deployment. You're saying, "don't bother, there's no 
IPv6 support on the last mile." We're saying "we're building the 
last mile, and we'd like to not have to wait for the next 
technology refresh cycle before the IPv6 support we build has any 
devices to use it." Understand that in many cases, even if the 
providers turned on IPv6 support in the CMTS or DSLAM/BRAS 
tomorrow, if the customer supplies their own modem or wireless 
gateway, if it doesn't do v6, it's also all for naught.


I don't think that it should be a serial process.  Although my 
earlier quote might not have emphasized it, doing this serially is 
like having a chicken and egg discussion.  I am not saying "don't 
bother".  You are building the "last mile" and you see a problem 
which occurs beyond the DSLAM/BRAS.  You don't want to wait for the 
next technology refresh cycle.  I agree with you on that.  I 
mentioned that the last mile can also be a problem (it may not be one 
from where you stand).


WEG] I fail to see the relevance of this other than to impugn the 
authors rather than the ideas in the draft, but since you brought it 
up, all 4 of the listed authors collaborated on the initial text of 
this draft at the end of IETF 79, and have provided material 
contributions to the text in each subsequent revision.


Thanks for the explanation.  For what it is worth, I made a similar 
comment about another draft ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68520.html 
).  Based on what you said above, there wasn't any desire for 
corporate name-dropping.


WEG] It would be helpful to know whether you do not support this 
because of the choice to update several RFCs, the choice to make it 
a proposed standard (instead of BCP or informational), or you 
disagree with the entire thing. This will make it easier for the 
authors to address your concerns adequately.


As I mentioned in a previous message, the draft comes out as a 
statement about "IPv6-required" instead of a Proposed 
Standard.  Irrespective of whether the document is a PS or BCP, it is 
important the ideas are clearly expressed.  Brian mentioned that the 
document can be fixed with some wordsmithing.  I made an attempt at 
"send text" ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68534.html ).  I 
came to the conclusion that the document needs more work before being 
ready for a Last Call.  The comment about informative v/s normative 
references ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68535.html ) was 
not made from a process perspective.  You can label it as editorial 
and I am not going to dispute the decision.  In the context of the 
document, I'll just read it as draft-ietf-6man-node-req-bis (or the 
existing RFC) can be overlooked.


I would not support the publication as the draft as Informational in 
its current form as it attempts to update several Standards Track 
RFCs.  You could try to get away with it by dropping the "Updates".


I agree with Tom Petch that the document comes out as utterly bizarre 
( http://www.ietf.org/mail-archive/web/ietf/current/msg68536.html 
).  I would not say that it seriously damages the Internet.  The 
document does not come out as a convincing argument to implement IPv6.


At 12:44 22-08-2011, George, Wesley wrote:
WEG] I think that you have a point that this update is a little weak 
in its current form. I don't have a problem with some clarifying 
text, but I think that the problem with the above is that you now 
get into situations where IPv4 internet connectivity by that 
definition is no longer possible due to a lack of available 
addresses. In other words, each of the defined items in the existing 
section 2 are applicable to IPv4 and IPv6 separately. So perhaps it 
needs to discuss the fact that there are now multiple permutations 
of the items in section 2, e.g. where the host has IPv6 internet


The multiple permutations ends up injecting complexity and can end up 
making the BCP "inaccessible".  As much as it is part of reality, it 
can end 

Re: Hyatt Taipei cancellation policy?

[Lixia Zhang]

On Aug 22, 2011, at 12:17 PM, Michael StJohns wrote:

> Hi folks - 
> 
> I just reserved with the hotel and was quite surprised at the cancellation 
> policy.
> 
> Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1 night, 
> after 7 Nov full amount?
> 
> Seriously?  This is extreme. I can understand a 1 day fee up to the date of 
> the reservation and maybe even charging the full amount if I don't cancel, 
> but paying $1500+ because I had to cancel at the last moment seems a bit 
> confiscatory.  
> 
> Mike

Since you brought up the subject of hotel: up to now IETF hotel prices have 
been within the federal per diem allowance, but IETF82 seems an exception by a 
pretty big gap (see 
http://aoprals.state.gov/web920/per_diem_action.asp?MenuHide=1&CountryCode=1142,
 lodging allowance $186/day, a single room at Hyatt is $263/day with 10% tax)


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

Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[George, Wesley]

From: SM 
To: Brian E Carpenter 
Reply-to: s...@resistor.net
Subject: Re: Last Call:  (IPv6 Support 
Required for all IP-capable nodes) to Proposed Standard

Section 2 of RFC 4084 lists the primary IP service terms:

(a) Web connectivity

(b) Client connectivity only, without a public address

(c) Client only, public address

(d) Firewalled Internet Connectivity

(e) Full Internet Connectivity

And with the proposed update:

(f) Version support.

Does the service include IPv4 support only, both IPv4 and IPv6
support, or IPv6 support only?

I don't think that it makes sense as it stands. If you want to
wordsmith this, you could go with:

(f) IPv4 Internet Connectivity.

This service provides the user IPv4 Internet connectivity, with
one or more static public IPv4 addresses. Dynamic IPv4 addresses
that are long-lived enough to make operating servers practical
without highly dynamic DNS entries are possible, provided that
they are not characterized as "dynamic" to third parties.


WEG] I think that you have a point that this update is a little weak in its 
current form. I don't have a problem with some clarifying text, but I think 
that the problem with the above is that you now get into situations where IPv4 
internet connectivity by that definition is no longer possible due to a lack of 
available addresses. In other words, each of the defined items in the existing 
section 2 are applicable to IPv4 and IPv6 separately. So perhaps it needs to 
discuss the fact that there are now multiple permutations of the items in 
section 2, e.g. where the host has IPv6 internet connectivity, but really only 
has client/no public IPv4 connectivity.
Then we're into value-judgment-land regarding whether full IPv6 connectivity 
coupled with NAT for IPv4 is considered "full internet connectivity" or if only 
true dual-stack is acceptable for that definition, etc.

Brian was the one who originally suggested this RFC be added as updated by this 
draft, so I'm keen to hear his opinion as well.


(g) IPv6 Internet Connectivity.

This service provides the user/consumer IPv6 Internet connectivity,
with at least a /60 IPv6 prefix. Dynamic IPv6 addressing that are
long-lived enough to make operating servers practical
without highly dynamic DNS entries are possible, provided that
they are not characterized as "dynamic" to third parties.
_
WEG] I think that this definition is going to be problematic. There are plenty 
of other documents which already define IPv6 connectivity, and we are unlikely 
to reach consensus on any definition that includes a prefix size, but I'd be 
interested in opinions on the rest of it assuming that the prefix size 
recommendation is dropped.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Hyatt Taipei cancellation policy?

[Michael StJohns]

Hi folks - 

I just reserved with the hotel and was quite surprised at the cancellation 
policy.

Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1 night, 
after 7 Nov full amount?

Seriously?  This is extreme. I can understand a 1 day fee up to the date of the 
reservation and maybe even charging the full amount if I don't cancel, but 
paying $1500+ because I had to cancel at the last moment seems a bit 
confiscatory.  

Mike

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

Re: Last Call: (IPv6Support Required for all IP-capable nodes) to Proposed Standard

[George, Wesley]

From: "t.petch" 
To: 
Reply-to: daedu...@btconnect.com
Subject: Re: Last Call:  (IPv6Support 
Required for all IP-capable nodes) to Proposed Standard

I find this document utterly bizarre and think it would seriously damage the
Internet to publish it.

WEG] well, I find the vehemence of your statement a bit bizarre, but I would 
like to address your concerns if possible. Please explain how a recommendation 
to support IPv6 is going to "seriously damage the internet."

The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is
fine, the sort of statement that the IAB should make, or have made, as an RFC or
in some other form.

WEG] Agree. IETF has remained version-agnostic for some time now. But they have 
not made anything like the statement that this draft makes, which is that IPv6 
will be necessary because IPv4 is going to have difficulties in continuing to 
provide the same level of service post-exhaustion. In the authors' opinions, it 
is long overdue as guidance to implementers, so we made the statement in the 
hopes that we'd reach consensus, which in a way is a stronger statement than 
something coming out of the IAB anyway.

But this I-D claims
" Updates [RFC1122] to clarify that this document, especially in
section 3, primarily discusses IPv4 where it uses the more generic
term "IP" and is no longer a complete definition of "IP" or the
Internet Protocol suite by itself. "

IPv4 is a phenomenal success, and RFC1122 is a key part of that. IPv4 was a
confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
through the cruft and rendered it usable. IPv6 desparately needs an equivalent
to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is
never going to be it, but claiming that this I-D provides an update to RFC1122,
coupled
with its title, gives the message that there is not going to be such an I-D;
IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
success of IPv4).
___
WEG] Ignoring for a moment the commentary on the state of the IPv6 RFCs vs 
IPv4, and the need for a "rosetta stone," I'll note that the choice to update 
several IP(v4) RFCs was something that has been controversial based on Intarea 
LC feedback as well, but we believed necessary to provide the linkage between 
the two. Honestly, I would have rather seen IETF issue formal updates to the 
existing "IP" RFCs to include IPv6, rather than building an entirely parallel 
set of documents, but here we are, so we made a choice. It would be helpful to 
understand whether your resistance to this document is solely due to the 
decision to have this be standards track, to update several existing RFCs, or 
both vs the general recommendation that implementers should support IPv6. While 
I believe that removing the update references will reduce the impact of the 
document, I am not opposed to issuing a new version of the document that does 
so and keeps to simply documenting the requirements for IPv6 
 support if consensus supports that action.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[George, Wesley]

From: SM 
To: ietf@ietf.org
Reply-to: s...@resistor.net
Subject: Re: Last Call:  (IPv6 Support 
Required for all IP-capable nodes) to Proposed Standard
X-RSN: 1/0/933/10475/58528

>From Section 1:

"However, due to the success of the Internet in finding new and
innovative uses for IP networking, billions of hosts are now
connected via the Internet and requiring unique addressing."

That sounds like the requirement for unique addressing is a
problem. The draft mentions that demand has lead to the exhaustion
of the IANA global pool of unique IPv4 addresses. Should the above
be read as "requiring unique IPv4 addressing"?
_
WEG] You're reading too much into this. It's a statement of the current 
situation, not a discussion about whether unique addresses are good or bad.
There are billions of hosts on the internet, a lot of them require unique 
addresses. End of line. No value judgment.
A requirement for unique addresses is not a problem. However, it *is* a problem 
if all you have to address those nodes  with is an exhausted IANA IPv4 free 
pool, which leaves us needing IPv6 to meet the demand for those unique 
addresses.


"However, the IPv6 deployment necessary to reduce reliance on IPv4 has
been hampered by a lack of ubiquitous hardware and software support
throughout the industry."

Quoting RFC 5218:

'The lack of a value chain can make it difficult for a new protocol to
progress from implementation to deployment to use. While the term
"chicken-and-egg" problem is sometimes used to describe the lack of a
value chain, the lack of implementation, deployment, or use is not
the cause of failure, it is merely a symptom.'

The assertion that the problem is a lack of ubiquitous hardware and
software support throughout the industry is incorrect. It is the
lack of the value chain that has hampered IPv6 deployment.
_
WEG] I find it strange that you'd a) quote from a section of 5218 on protocol 
failure in a discussion about IPv6, which doesn't meet any of the criteria 
listed earlier in that section and b) invoke a value chain here as a reason to 
invalidate the above statement. Whether it's a cause or a symptom, the above 
quoted issue still exists as a barrier, and ultimately the lack of that support 
breaks that chain - no killer app making it attractive to move to IPv6 due to 
concerns that the target audience wouldn't be able to reach it, due to a lack 
of last mile support for IPv6, for example. I think this argument is mostly 
based on your following assertion, so I'll respond in more detail below.


Many vendors in the consumer space such as Internet Service Providers
still view IPv6 support as optional. They are still pushing the
"Internet" as an IPv4 medium only.

Even if the average home gets an IPv6-capable device, that would not
get it any further due to last-mile issues.

___
WEG] As an operator (consumer ISP) who happens to spend a lot of time talking 
about IPv6 deployments with other operators, I disagree with this assertion. 
This is exactly the problem we're trying to solve. From where I sit, I see 
credible plans from a number of US residential broadband providers to have IPv6 
enabled on a large portion of their footprint within the next 12-18 months. 
There is no reason why IPv6 support in ancillary devices needs to be a serial 
process dependent on completion of that last mile deployment. You're saying, 
"don't bother, there's no IPv6 support on the last mile." We're saying "we're 
building the last mile, and we'd like to not have to wait for the next 
technology refresh cycle before the IPv6 support we build has any devices to 
use it." Understand that in many cases, even if the providers turned on IPv6 
support in the CMTS or DSLAM/BRAS tomorrow, if the customer supplies their own 
modem or wireless gateway, if it doesn't do v6, it's also all for n
 aught.

Anyway, let's get to the meat of the draft.
__
WEG] Brian's already responded to several of these items, so I'll respond 
inline in those messages as necessary.


BTW, this draft has nine pages and four authors. The 162-page draft
I read recently has five authors. "If there is a desire to
demonstrate how many companies are interested in this spec, a simple
acknowledgment section can accomplish the same thing".
___
WEG] I fail to see the relevance of this other than to impugn the authors 
rather than the ideas in the draft, but since you brought it up, all 4 of the 
listed authors collaborated on the initial text of this draft at the end of 
IETF 79, and have provided material contributions to the text in each 
subsequent revision.


I do not support the publication of this document as a RFC. It
attempts to update old RFCs which are well-written in a confusing
manner. The draft comes out as a statement about "IPv6-required"
instead of a Proposed Standard.
__
WEG] It would be helpful to know whether you do not support this because of the 
choice to update several RFCs, the choice to make it a 

Re: [precis] Path towards a multilingalization IUse referent

[Masataka Ohta]

Worley, Dale R (Dale) wrote:

> But in my social context, when someone argues for a universal
> communication system, they usually continue with a demand that
> everybody speaks English.  And I don't think that's what we intend.
> (<-- this is a joke)

You are confusing characters and languages.

Plain DNS is already multilingual, because all the languages in the
world can be represented in ASCII characters.

Adding fancy characters means most of the international people can't
recognize the characters, which is against Internationalization.

That is, plain DNS with ASCII is the most internationalized DNS.

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

RE: [precis] Path towards a multilingalization IUse referent

[Worley, Dale R (Dale)]

> From: Andrew Sullivan
> 
> On Sun, Aug 21, 2011 at 01:08:29AM +0200, jefsey wrote:
> > However, the Internet MUST be supported by a
> > network/human oriented universal semiotic system.
> 
> I would like a defence of that claim.  Speaking entirely personally, I
> don't believe it.

Hmmm, my opinion is that I would be pleased if I understood the
demand.

But in my social context, when someone argues for a universal
communication system, they usually continue with a demand that
everybody speaks English.  And I don't think that's what we intend.
(<-- this is a joke)

But there is a similar danger with any "universal semiotic system", in
that the more systematic we make it, the less well it aligns with many
of the thousands of human cultures  (<-- this is not a joke)

(In critiques of the Pioneer plaque it was noted that the "arrow" as a
textual convention depends on a cultural history of bow-and-arrow
use.  So much for universal symbols.)

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

Re: IDNA and Multilingual Internet issues and vocabulary after IDNA2008

[Hector Santos]

Not commenting of the legal stuff,  I have to admit I like the idea of 
the Glossary web site with the consolidation of divest material.  I 
thought it had some awkward reading injection of material that 
probably was not necessary, maybe little unprofessional, but overall 
for such a divest environment on the Internet, the basic Glossary idea 
was interesting that I found to be informational. I think it will 
gives people, especially for the new, a better sense of the global 
connected nature of the various groups. If anything, there was an 
initial perception of commercial interest, but that didn't seem to be 
the case. But your email was definitely presented that way or at least 
its how I read it for a person who didn't know much about all these 
groups.  Maybe didn't help if that was not the intent.


Anyway, I hope the "legal" stuff can be settled.  It would be a 
resource link for me.



jean-michel bernier de portzamparc wrote:

Dear Mr. Klensin,

"we" are Internet and IETF users. This makes a pretty large community. There
are three ways one can do it:

- in surviving with what we (do not) get. Very large part of our community.
- in hacking the internet from the outside on behalf of our right to protect
ourselves from digital ecosystem pollution risks. Small part of our
community.
- in trying to cooperate with you guys and help your inside work with our
outside perspective. Microscopic part of our community. Guess why? Please
read the begining of your mail.

We do it because Jefsey convinced a few of us and the IETF Chair that it had
to be tried. However, if the inside Internet is made of individual's and
ISOC's copyrights and cannot even be discussed and helped, Jefsey will soon
be alone!

Please respond: the ball is your field. Tell me: are we wrong trying to work
in the open, liaise with the IETF and carry a lot of work to be able to
answer you, the happiana, the PRECIS, the VIP people in a consistant way,
also with other open works?


This being said you perfectly know that this

2011/8/19 John C Klensin 


without any specific
attribution or acknowledgment.  Those materials include several
RFCs and draft-ietf-appsawg-rfc3536bis.



is wrong. Your name, your RFCs etc. are quoted as such. We do not publish,
we try to draft a pertinent mail to you!



I am an author or major
contributor on several of those.  Especially since I had asked
earlier that any compendium of this sort list terms covered in
other documents, comment on them as you thought appropriate,



This is correct. But to respond to you, a lot of work must be carried.
Beginning with an enlarged scope to other intricate real needs you did not
consider yet.

Portzamparc

BTW I am not French, I am Breton!





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


--
Sincerely

Hector Santos
http://www.santronics.com



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

Question about Policy Announcement and Query...

[Todd Glassey]

Would a general access policy lookup tool protocol be viable here?  It 
could bolt-on to both DHCP and NEA but seems like the same additions 
would be good in both. The same is true with many other protocols. 
Especially (from my perspective) those being used in automation and 
testimony generation models.


The logic is that today we need to be able to do a complete business 
relationship online and not have to use HTTP as the basis of it. The 
nexus of this is that there really needs to be some way on the web of 
asking for and receiving the use policy for other network services (DNS, 
Email, DHCP, SSH, L2TP, SNMP, etc etc etc) than a web-interface.


This may be as simple as a use model for an existing set of tools - so 
it may be we just need use statements for fulfilling this requirement 
today.


But this brings up a stronger and more subtler argument as to whether 
standards need this type of thing - the ability to communicate the rules 
of engagement inside the context of the specific standard or as an 
alternative through a unified interface standard


Either way, I still want to propose the idea of a Project to come up 
with a proposal for a WG which would handle a uniform Policy Discovery 
Transport thingee and its use models.


I think the PDT should be adapted so it can provide these services to 
existing protocols where applicable as well inside the IETF's stable of 
IP. This allows for some pretty strong packaging options to the Trust as 
well so its probably a double whammy


My suggestion - forget its me suggesting it and just consider the idea 
on the merits of the Idea - you guys can pick someone to run this and 
produce the whole thing, I just want to propose here that this is a 
missing piece of your cake. Its the icing for a number of tools you 
already have locked-down tight so its got value and legs I think.


Todd


--
Todd S. Glassey - CISM CIFI
CTO Certichron Inc

This message contains information which may be confidential and/or privileged. 
Unless you are the intended recipient (or authorized to receive for the 
intended recipient), you may not read, use, copy or disclose to anyone the 
message or any information contained in the message. If you have received the 
message in error, please advise the sender by reply e-mail and delete the 
message and any attachment(s) thereto without retaining any copies.

Further we have a formal OPT OUT Policy posted on our website pertaining to the 
use of any Email Addresses gleaned or taken from any source, web, mailing 
lists, previous customer lists etc. In all instances we choose to formally OPT 
OUT and this notice constitutes formal disclosure that you may not collect, buy 
or sell or provide access to this email address or any pertaining to our DNS MX 
Record Publication License posted on the web at 
http://www-wp.certichron.com/?page_id=3947.

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

Re: [mpls] Last Call: (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard

[venkatesan mahalingam]

Eric,

Don't you feel that uniformity should be maintained on AGI field
representation for on-demand and proactive OAM operations?

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AGI Type|  AGI Length   |  AGI Value|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~AGI  Value (contd.)~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-mpls-tp-cc-cv-rdi-06, section 3.5.3. PW Endpoint MEP-ID and
draft-ietf-mpls-tp-on-demand-cv-06, section 2.3.2.  Static Pseudowire
Sub-TLV conflict in representing the AGI field.

Why are we not following this generic format for representing the AGI field?

Am I missing something?

Thanks,
Venkat.

Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05

To: binny jeshan , "mpls at ietf.org" 
Subject: Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05
From: Eric Gray 
Date: Thu, 11 Aug 2011 07:03:09 -0400
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ross Callon , MPLS-TP ad hoc team
, "draft-ietf-mpls-tp-on-demand-cv at
tools.ietf.org" 
Delivered-to: mpls at ietfa.amsl.com
In-reply-to: 
List-archive: 
List-help: 
List-id: Multi-Protocol Label Switching WG 
List-post: 
List-subscribe: ,

List-unsubscribe: ,

References: 
Thread-index: AcxAZ8Iuor4OYFULT7mPiL+c0YrKTgXrKqiA
Thread-topic: Need clarification on draft-ietf-mpls-tp-on-demand-cv-05
Binny,

We discussed this in detail.  Superficially, this seemed like a great idea,
with precedents in the CC/CV/RDI draft.

The issues we ran into include:
1) the Static PW ID TLV is already a sub-TLV; there are issues and a very
undesirable precedent associated with creating a sub-TLV for a sub-TLV.
2) the flexibility associated with inheriting the type code also poses a risk;
we cannot know in advance what other AGI types might be invented in
the future, and whether or not it would make sense in then existing TP
implementations to support generally the new type(s) as part of the
Static PW Identifier Sub-TLV.

What we decided to do was to change the name of the field to "Service
Identifier" - which will be an unsigned integer and which may contain a type
0x01 AGI, for example.  Because it is an unsigned integer, it may also be
used to contain anything smaller than 64 bits.

The flexibility to support other AGI types still exists, should it become
necessary to do so.  In that event, we could define additional Static PW
Sub-TLV type(s) to support any AGI type(s) that make sense at that time.

Thanks for your thoughtful and thought-provoking input! We appreciate
your putting time into reviewing our draft...

--
Eric

On Sun, Aug 21, 2011 at 1:48 PM, venkatesan mahalingam
 wrote:
> Hi,
>
> I don't see any TLVs defined for performing the on-demand CV operation
> on MPLS -TP Sections. Is this intentional?
>
> and
>
> Co-routed bidirectional tunnel identifier:
> A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
>      Node_ID::Tunnel_Num}::LSP_Num
> Associated bidirectional tunnel identifier:
> A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
>      Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
>
> How does Static LSP Sub-TLV address the need of two LSP_Nums of
> associated bidirectional tunnel?
>
> Am I missing something?
>
> Thanks,
> Venkat.
>
> On Fri, Aug 19, 2011 at 5:50 AM, Mach Chen  wrote:
>> Hi,
>>
>> One question about the difference of the encapsulation modes between CV and 
>> Route Tracing.
>>
>> In Section 3, there are three encapsulation modes for on-demand CV: 
>> "LSP-Ping with IP encapsulation", "On-demand CV with IP encapsulation, over 
>> ACH" and "Non-IP based On-demand CV, using ACH", but for On-demand Route 
>> Tracing (in section 4), there are only two modes: "On-demand LSP Route 
>> Tracing with IP encapsulation" and "Non-IP based On-demand LSP Route 
>> Tracing, using ACH". Seems that there should be "On-demand LSP Route Tracing 
>> with IP encapsulation, over ACH" accordingly. What's reason behind this? Or 
>> maybe I missed something.
>>
>> Best regards,
>> Mach
>>
>>> -Original Message-
>>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The
>>> IESG
>>> Sent: Thursday, August 11, 2011 9:46 PM
>>> To: IETF-Announce
>>> Cc: m...@ietf.org
>>> Subject: [mpls] Last Call:  (MPLS
>>> On-demand Connectivity Verification and Route Tracing) to Proposed Standard
>>>
>>>
>>> The IESG has received a request from the Multiprotocol Label Switching WG
>>> (mpls) to consider the following document:
>>> - 'MPLS On-demand Conne

Re: [mpls] Last Call: (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard

[venkatesan mahalingam]

Hi,

I don't see any TLVs defined for performing the on-demand CV operation
on MPLS -TP Sections. Is this intentional?

and

Co-routed bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
  Node_ID::Tunnel_Num}::LSP_Num
Associated bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
  Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}

How does Static LSP Sub-TLV address the need of two LSP_Nums of
associated bidirectional tunnel?

Am I missing something?

Thanks,
Venkat.

On Fri, Aug 19, 2011 at 5:50 AM, Mach Chen  wrote:
> Hi,
>
> One question about the difference of the encapsulation modes between CV and 
> Route Tracing.
>
> In Section 3, there are three encapsulation modes for on-demand CV: "LSP-Ping 
> with IP encapsulation", "On-demand CV with IP encapsulation, over ACH" and 
> "Non-IP based On-demand CV, using ACH", but for On-demand Route Tracing (in 
> section 4), there are only two modes: "On-demand LSP Route Tracing with IP 
> encapsulation" and "Non-IP based On-demand LSP Route Tracing, using ACH". 
> Seems that there should be "On-demand LSP Route Tracing with IP 
> encapsulation, over ACH" accordingly. What's reason behind this? Or maybe I 
> missed something.
>
> Best regards,
> Mach
>
>> -Original Message-
>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The
>> IESG
>> Sent: Thursday, August 11, 2011 9:46 PM
>> To: IETF-Announce
>> Cc: m...@ietf.org
>> Subject: [mpls] Last Call:  (MPLS
>> On-demand Connectivity Verification and Route Tracing) to Proposed Standard
>>
>>
>> The IESG has received a request from the Multiprotocol Label Switching WG
>> (mpls) to consider the following document:
>> - 'MPLS On-demand Connectivity Verification and Route Tracing'
>>    as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>    Label Switched Path Ping (LSP-Ping) is an existing and widely
>>    deployed Operations, Administration and Maintenance (OAM) mechanism
>>    for Multi-Protocol Label Switching (MPLS) Label Switched Paths
>>    (LSPs).  This document describes extensions to LSP-Ping so that LSP-
>>    Ping can be used for On-demand Connectivity Verification of MPLS
>>    Transport Profile (MPLS-TP) LSPs and Pseudowires.  This document also
>>    clarifies procedures to be used for processing the related OAM
>>    packets.  Further, it describes procedures for using LSP-Ping to
>>    perform Connectivity Verification and Route Tracing functions in
>>    MPLS-TP networks.  Finally this document updates RFC 4379 by adding a
>>    new address type and requesting an IANA registry.
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>> ___
>> mpls mailing list
>> m...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Thomas Nadeau]

On Aug 19, 2011, at 5:09 PM, Luca Martini wrote:

> On 08/19/11 14:53, John E Drake wrote:
>> Luca,
>> 
>> So, you are considering weighted ECMP, with FAT and entropy label, to be an 
>> application?  We are also releasing the GAL to float until it finds its 
>> proper level within the MPLS label stack?
> Yes. It certainly addresses a specific problem that is only a concern in
> some networks.
> Maybe as application I meant the specific technology documents. For
> example if an OAM method needs to use the GAL for a specific purpose it
> should specify it there, without us putting restrictions in a generic
> way in this document.
> 
> As for the float part, I consider the GAL to be a simple Flag that says
> " following the MPLS label stack , you will find a GACh construct , and
> not an IP packet"

This makes a lot of sense to me as it makes sure that the specific 
applications use the GAL as needed. This document should just lay out the 
generic rules for using it, but not preclude its use by some application we 
have not through of yet down the road by making rules that are too narrow.

--Tom


> In MPLS the default is to have an IP packet, unless a different meaning
> is bound to the label by the control plane. Thsi is the reason we needed
> the GAL in the first place for the MPLS-TP environment , where IP is not
> used.
> 
> Thanks,
> Luca
> 
>> Thanks,
>> 
>> John
>> 
>> Sent from my iPhone
>> 
>> 
>>> -Original Message-
>>> From: Luca Martini [mailto:lmart...@cisco.com]
>>> Sent: Friday, August 19, 2011 1:17 PM
>>> To: John E Drake
>>> Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir
>>> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
>>> Rotem Cohen
>>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
>>> gal-in-pw
>>> 
>>> John,
>>> 
>>> 
>>> I would like to  let applications decide how they design the use of the
>>> gal.
>>> 
>>> So I would propose a simple change , that will move any discussions to
>>> the specific applications:
>>> 
>>> The next text would be as follows:
>>> 
>>> 
>>> 
>>> -  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
>>>  original text:
>>> 
>>>  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>>>  LSPs, Concatenated Segments of LSPs, and with Sections, and
>>>  MUST NOT be used with PWs. It MUST always be at the bottom of
>>>  the label stack (i.e., S bit set to 1). However, in other
>>> MPLS
>>>  environments, this document places no restrictions on where
>>>  the GAL may appear within the label stack or its use with
>>> PWs.
>>> 
>>>  is replaced by:
>>> 
>>>  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>>>  LSPs, Concatenated Segments of LSPs, and with Sections, and
>>>  MAY be used with PWs.
>>> 
>>> 
>>> 
>>> Does this work ?
>>> Thanks.
>>> Luca
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 08/18/11 08:00, John E Drake wrote:
 Sasha,
 
 I completely agree with your recommendations:
 
 - releasing the bottom-of-stack requirement on GAL
 
 - making use of the statement in RFC 5586 that if GAL is encountered
>>> in a packet then G-ACh header MUST be present immediately after the
>>> bottom of the label stack (and not immediately after GAL)
 - specifying that ECMP on labeled packets MUST ignore reserved labels
 
 Thanks,
 
 John
 
 Sent from my iPhone
 
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
>>> Of
> Alexander Vainshtein
> Sent: Wednesday, August 17, 2011 9:52 PM
> To: Luca Martini
> Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-
>>> pwe3-
> gal-in-pw
> 
> Luca and all,
> I have not found the statement you've proposed in draft-ietf-pwe3-
>>> fat-
> pw-06. Instead, it contans the following text in Section 8.5 "
> Applicability to MPLS-TP":
> 
> 
>   The flow aware transport of a PW reorders packets, therefore MUST
> NOT be
>   deployed in a network conforming to the MPLS-TP unless these
> integrity requirements
>   specified in the SLA can be satisfied.
> 
> 
> (In the -07 version this text is repeated but followed by an
>>> incomplete
> statement " In a" immediately followed by the heading of Section
>>> 8.6.
> Since this addition is difficult to parse, I will ignore it for the
> moment.)
> 
> IMHO and FWIW this means that prohibition on using flow aware PW in
> MPLS-TP environments is conditional on meeting specific SLA
> requirements for the service. So I think that the use case I've
> presented still holds.
> 
> Please note also that, regardless of the restriction in draft-ietf-

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Luca Martini]

On 08/19/11 14:53, John E Drake wrote:
> Luca,
>
> So, you are considering weighted ECMP, with FAT and entropy label, to be an 
> application?  We are also releasing the GAL to float until it finds its 
> proper level within the MPLS label stack?
Yes. It certainly addresses a specific problem that is only a concern in
some networks.
Maybe as application I meant the specific technology documents. For
example if an OAM method needs to use the GAL for a specific purpose it
should specify it there, without us putting restrictions in a generic
way in this document.

As for the float part, I consider the GAL to be a simple Flag that says
" following the MPLS label stack , you will find a GACh construct , and
not an IP packet"

In MPLS the default is to have an IP packet, unless a different meaning
is bound to the label by the control plane. Thsi is the reason we needed
the GAL in the first place for the MPLS-TP environment , where IP is not
used.

Thanks,
Luca

> Thanks,
>
> John
>
> Sent from my iPhone
>
>
>> -Original Message-
>> From: Luca Martini [mailto:lmart...@cisco.com]
>> Sent: Friday, August 19, 2011 1:17 PM
>> To: John E Drake
>> Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir
>> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
>> Rotem Cohen
>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
>> gal-in-pw
>>
>> John,
>>
>>
>> I would like to  let applications decide how they design the use of the
>> gal.
>>
>> So I would propose a simple change , that will move any discussions to
>> the specific applications:
>>
>> The next text would be as follows:
>>
>>
>>
>> -  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
>>   original text:
>>
>>   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>>   LSPs, Concatenated Segments of LSPs, and with Sections, and
>>   MUST NOT be used with PWs. It MUST always be at the bottom of
>>   the label stack (i.e., S bit set to 1). However, in other
>> MPLS
>>   environments, this document places no restrictions on where
>>   the GAL may appear within the label stack or its use with
>> PWs.
>>
>>   is replaced by:
>>
>>   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>>   LSPs, Concatenated Segments of LSPs, and with Sections, and
>>   MAY be used with PWs.
>>
>>
>>
>> Does this work ?
>> Thanks.
>> Luca
>>
>>
>>
>>
>>
>>
>> On 08/18/11 08:00, John E Drake wrote:
>>> Sasha,
>>>
>>> I completely agree with your recommendations:
>>>
>>> - releasing the bottom-of-stack requirement on GAL
>>>
>>> - making use of the statement in RFC 5586 that if GAL is encountered
>> in a packet then G-ACh header MUST be present immediately after the
>> bottom of the label stack (and not immediately after GAL)
>>> - specifying that ECMP on labeled packets MUST ignore reserved labels
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> Sent from my iPhone
>>>
 -Original Message-
 From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
>> Of
 Alexander Vainshtein
 Sent: Wednesday, August 17, 2011 9:52 PM
 To: Luca Martini
 Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
 Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
 Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-
>> pwe3-
 gal-in-pw

 Luca and all,
 I have not found the statement you've proposed in draft-ietf-pwe3-
>> fat-
 pw-06. Instead, it contans the following text in Section 8.5 "
 Applicability to MPLS-TP":

 
The flow aware transport of a PW reorders packets, therefore MUST
 NOT be
deployed in a network conforming to the MPLS-TP unless these
 integrity requirements
specified in the SLA can be satisfied.
 

 (In the -07 version this text is repeated but followed by an
>> incomplete
 statement " In a" immediately followed by the heading of Section
>> 8.6.
 Since this addition is difficult to parse, I will ignore it for the
 moment.)

 IMHO and FWIW this means that prohibition on using flow aware PW in
 MPLS-TP environments is conditional on meeting specific SLA
 requirements for the service. So I think that the use case I've
 presented still holds.

 Please note also that, regardless of the restriction in draft-ietf-
 pwe3-fat-pw, be it conditional or absolute, usage of flow labels in
>> an
 MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the
 label stack and taking one of multiple NHLFEs for the given incoming
 label in the ILM) were not used in this domain, e.g., by associating
 exactly one ILM entry with each incoming label in the ILM. And since
 MPLS-TP is supposed to carry not just PW clients but also IP ones, I
 would expect that this would be the case in any MPLS-TP deployment.

 I also think that releasi

RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[John E Drake]

Luca,

So, you are considering weighted ECMP, with FAT and entropy label, to be an 
application?  We are also releasing the GAL to float until it finds its proper 
level within the MPLS label stack?

Thanks,

John

Sent from my iPhone


> -Original Message-
> From: Luca Martini [mailto:lmart...@cisco.com]
> Sent: Friday, August 19, 2011 1:17 PM
> To: John E Drake
> Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir
> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
> Rotem Cohen
> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
> gal-in-pw
>
> John,
>
>
> I would like to  let applications decide how they design the use of the
> gal.
>
> So I would propose a simple change , that will move any discussions to
> the specific applications:
>
> The next text would be as follows:
>
>
>
> -  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
>   original text:
>
>   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>   LSPs, Concatenated Segments of LSPs, and with Sections, and
>   MUST NOT be used with PWs. It MUST always be at the bottom of
>   the label stack (i.e., S bit set to 1). However, in other
> MPLS
>   environments, this document places no restrictions on where
>   the GAL may appear within the label stack or its use with
> PWs.
>
>   is replaced by:
>
>   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
>   LSPs, Concatenated Segments of LSPs, and with Sections, and
>   MAY be used with PWs.
>
>
>
> Does this work ?
> Thanks.
> Luca
>
>
>
>
>
>
> On 08/18/11 08:00, John E Drake wrote:
> > Sasha,
> >
> > I completely agree with your recommendations:
> >
> > - releasing the bottom-of-stack requirement on GAL
> >
> > - making use of the statement in RFC 5586 that if GAL is encountered
> in a packet then G-ACh header MUST be present immediately after the
> bottom of the label stack (and not immediately after GAL)
> >
> > - specifying that ECMP on labeled packets MUST ignore reserved labels
> >
> > Thanks,
> >
> > John
> >
> > Sent from my iPhone
> >
> >> -Original Message-
> >> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
> Of
> >> Alexander Vainshtein
> >> Sent: Wednesday, August 17, 2011 9:52 PM
> >> To: Luca Martini
> >> Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
> >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
> >> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-
> pwe3-
> >> gal-in-pw
> >>
> >> Luca and all,
> >> I have not found the statement you've proposed in draft-ietf-pwe3-
> fat-
> >> pw-06. Instead, it contans the following text in Section 8.5 "
> >> Applicability to MPLS-TP":
> >>
> >> 
> >>The flow aware transport of a PW reorders packets, therefore MUST
> >> NOT be
> >>deployed in a network conforming to the MPLS-TP unless these
> >> integrity requirements
> >>specified in the SLA can be satisfied.
> >> 
> >>
> >> (In the -07 version this text is repeated but followed by an
> incomplete
> >> statement " In a" immediately followed by the heading of Section
> 8.6.
> >> Since this addition is difficult to parse, I will ignore it for the
> >> moment.)
> >>
> >> IMHO and FWIW this means that prohibition on using flow aware PW in
> >> MPLS-TP environments is conditional on meeting specific SLA
> >> requirements for the service. So I think that the use case I've
> >> presented still holds.
> >>
> >> Please note also that, regardless of the restriction in draft-ietf-
> >> pwe3-fat-pw, be it conditional or absolute, usage of flow labels in
> an
> >> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the
> >> label stack and taking one of multiple NHLFEs for the given incoming
> >> label in the ILM) were not used in this domain, e.g., by associating
> >> exactly one ILM entry with each incoming label in the ILM. And since
> >> MPLS-TP is supposed to carry not just PW clients but also IP ones, I
> >> would expect that this would be the case in any MPLS-TP deployment.
> >>
> >> I also think that releasing one restriction (on using GAL in PWs) at
> >> the expense of making another, conditional one (on usage of flow
> labels
> >> in MPLS-TP environments) absolute is not the most appropriate method
> >> for resolving technical issues. IMHO and FWIW better way to resolve
> the
> >> problem would be by:
> >>
> >> - releasing the bottom-of-stack requirement on GAL
> >> - making use of the statement in RFC 5586 that if GAL is encountered
> in
> >> a packet then G-ACh header MUST be present immediately after the
> bottom
> >> of the label stack (and not immediately after GAL)
> >> - specifying that ECMP on labeled packets MUST ignore reserved
> labels.
> >>
> >> I think that these considerations have been presented already in the
> >> discussion on draft-nadeau-pwe-vccv-2.
> >>
> >> Of course it would be even better if we could agr

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Luca Martini]

John,


I would like to  let applications decide how they design the use of the gal.

So I would propose a simple change , that will move any discussions to
the specific applications:

The next text would be as follows:



-  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
  original text:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MUST NOT be used with PWs. It MUST always be at the bottom of
  the label stack (i.e., S bit set to 1). However, in other MPLS
  environments, this document places no restrictions on where
  the GAL may appear within the label stack or its use with PWs.

  is replaced by:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MAY be used with PWs.



Does this work ?
Thanks.
Luca






On 08/18/11 08:00, John E Drake wrote:
> Sasha,
>
> I completely agree with your recommendations:
>
> - releasing the bottom-of-stack requirement on GAL
>
> - making use of the statement in RFC 5586 that if GAL is encountered in a 
> packet then G-ACh header MUST be present immediately after the bottom of the 
> label stack (and not immediately after GAL)
>
> - specifying that ECMP on labeled packets MUST ignore reserved labels
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>> -Original Message-
>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
>> Alexander Vainshtein
>> Sent: Wednesday, August 17, 2011 9:52 PM
>> To: Luca Martini
>> Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
>> gal-in-pw
>>
>> Luca and all,
>> I have not found the statement you've proposed in draft-ietf-pwe3-fat-
>> pw-06. Instead, it contans the following text in Section 8.5 "
>> Applicability to MPLS-TP":
>>
>> 
>>The flow aware transport of a PW reorders packets, therefore MUST
>> NOT be
>>deployed in a network conforming to the MPLS-TP unless these
>> integrity requirements
>>specified in the SLA can be satisfied.
>> 
>>
>> (In the -07 version this text is repeated but followed by an incomplete
>> statement " In a" immediately followed by the heading of Section 8.6.
>> Since this addition is difficult to parse, I will ignore it for the
>> moment.)
>>
>> IMHO and FWIW this means that prohibition on using flow aware PW in
>> MPLS-TP environments is conditional on meeting specific SLA
>> requirements for the service. So I think that the use case I've
>> presented still holds.
>>
>> Please note also that, regardless of the restriction in draft-ietf-
>> pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an
>> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the
>> label stack and taking one of multiple NHLFEs for the given incoming
>> label in the ILM) were not used in this domain, e.g., by associating
>> exactly one ILM entry with each incoming label in the ILM. And since
>> MPLS-TP is supposed to carry not just PW clients but also IP ones, I
>> would expect that this would be the case in any MPLS-TP deployment.
>>
>> I also think that releasing one restriction (on using GAL in PWs) at
>> the expense of making another, conditional one (on usage of flow labels
>> in MPLS-TP environments) absolute is not the most appropriate method
>> for resolving technical issues. IMHO and FWIW better way to resolve the
>> problem would be by:
>>
>> - releasing the bottom-of-stack requirement on GAL
>> - making use of the statement in RFC 5586 that if GAL is encountered in
>> a packet then G-ACh header MUST be present immediately after the bottom
>> of the label stack (and not immediately after GAL)
>> - specifying that ECMP on labeled packets MUST ignore reserved labels.
>>
>> I think that these considerations have been presented already in the
>> discussion on draft-nadeau-pwe-vccv-2.
>>
>> Of course it would be even better if we could agree on transition to
>> universal usage of the CW and VCCV Type  1 in PWs. But this is a
>> different story.
>>
>> Regards,
>> Sasha
>> 
>> From: Luca Martini [lmart...@cisco.com]
>> Sent: Wednesday, August 17, 2011 9:58 PM
>> To: Alexander Vainshtein
>> Cc: Pablo Frank; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan
>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
>> Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
>>
>> The solution is quite simple:
>>
>> "Flow Labels MUST not be used in an MPLS-TP environment."
>>
>> Luca
>>
>>
>>
>>
>>
>> On 08/16/11 21:46, Alexander Vainshtein wrote:
>>> Pablo,
>>> Sorry, but I think you're wrong. Only T-PE can insert the flow label
>>> (because only T=PE can be "flow-aware"). S-PE simply performs swap on
>>> PW lab

Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth

[Henry B. Hotz]

I don't believe any of my desirements justifies holding up publication.

Practically speaking, I'm most interested in the "disconnected" case.  It 
should also be the easiest to test thoroughly.  I also believe the draft is 
good enough for this case.  I would very much like to see client code capable 
of handling it widely deployed so I don't have to.

I would like to see some indication that the specification is sufficient for 
some realistic connected token, but I'm not sure I'm qualified to judge that.  
I have not been looking at that case.  (Yubikey doesn't count.)

I would also like some better indication that the pin change stuff can work, 
but I expect pin changes to be "out of band" for anything I'm currently 
contemplating deploying.  If no one else volunteers, I can probably look at 
that again within the next few weeks.

> I'm thinking it would be useful to at least work out how a interoperable
> profile of one OTP mechanism such as HOTP would work.  I have some
> cycles to work on such a profile, but I would need help (any takers?).

Glad to help.  No promises about speed of turnaround for my feedback, but 
please CC me at least.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu

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

Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[George, Wesley]

From: Keith Moore 
To: ietf@ietf.org
Subject: Re: Last Call:  (IPv6 Support 
Required for all IP-capable nodes) to Proposed Standard

I support publication of some document like this one. Suggestions for 
clarification to this document:

1. (section 2 in general) I think it's vague for this document to claim that it 
"updates" earlier documents as if it's changing the text of those documents.
The reader is left with only a vague impression of what is still in place from 
those documents and what has changed.

I suggest that the language in this draft be changed to first state each new or 
revised requirement, and then state how this changes
recommendations/requirements stated in earlier documents.
__
WEG] We received similar feedback in the intarea last call, the "Updates..." 
language in section two is an attempt to do this clarification and is far more 
specific than the 00 version. It was attempting to note that rather than 
updating the details of the technical specs, it was pointing out that IP as 
generic could mean IPv4 or IPv6, but these documents are clearly IPv4 
documents. Think of it as equivalent to %s/IP/IPv4/g. Since it appears that 
this was not completely successful, I'd appreciate more specific feedback or 
text suggestions to make it better.

2. section 2, page 4 reads:

reason: to me "SHOULD NOT support IPv4 only" seems potentially confusing.
__
WEG] agree, will fix in next rev.

3. section 2, page 5 reads:

New IP implementations MUST support IPv6.

Current IP implementations SHOULD support IPv6.

In general, it's meaningless to impose a requirement on current implementations 
of anything.

WEG] This is why it's a SHOULD instead of a MUST. Also, generally this document 
is saying "the IETF recommends that you support IPv6" so it seems a gap to 
leave out current implementations. This is also why the last paragraph in 
section 2 is there - we realize that there are going to be limitations to this 
and are trying to be pragmatic.

 Also, it's not clear what is meant by "new implementations" -
does this mean completely new implementations, or revisions of existing 
implementations?

WEG] I'm wondering if it actually matters in this context? They both need to 
support IPv6, which is why both requirements are there. Ultimately, this is 
going to be open to interpretation by implementers regardless of how it is 
worded. Since the IETF has no control over what they decide to do, if they 
choose to interpret their implementation as not new and therefore covered by 
the SHOULD instead of the MUST, IETF has no recourse if they disagree with that 
interpretation.
That said, I am certainly open to additional text to clarify what "new 
implementations" are vs "current implementations" if you believe that it'll be 
helpful.

Suggest that this be restated. e.g. "Host and router IP implementations MUST 
support IPv6; to support only IPv4 is insufficient."

WEG] This may be a way to solve. We'll consider in the revision.

4. also section 2, page 5:

IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.

This statement could be taken too broadly, e.g. as applying to service 
offerings rather than just host and router implementations.
_
WEG] It was intended to be taken as broadly as possible. It's not necessarily 
limited to host and router implementations, though that is indeed its primary 
focus. How is it a bad thing if a service offering interprets this to mean that 
the IETF recommends that they support IPv6?


Suggest instead:
Support for the IPv6 protocol in hosts and routers MUST
be equivalent or better in quality and functionality when
compared to IPv4 support in the same products.

Even then, this strikes me as problematic. Should an implementation that cannot 
provide support for every IPv6 feature (perhaps because of inherent
differences between IPv4 and IPv6, or because some feature hasn't yet been 
updated to support IPv6) be expected to remove features from its IPv4 stack so 
that
its IPv6 stack is "equivalent or better"?
__
WEG] For what it's worth, I'm aware of several businesses that are using 
language similar to this in their vendor requirements documents. Basically, 
making it incumbent on the implementer to ensure that their gear supports 
features in both IPv4 and IPv6 rather than calling out specific features and 
thus risking missing some. So, I think the answer to your question is that it's 
a business decision on the part of the implementer. Some of the very early 
comments we received on this draft indicated a concern that people would 
implement the bare minimum IPv6 support and call it a day, making it mostly 
useless by comparison because it was so limited in functionality. This more 
generic text was chosen to cover this concern without getting us ratholed into 
a discussion about whether (for example) NAT is required in IPv6 b

Re: Last Call:

[Frank Ellermann]

Nothing is wrong in BCP 104, it needs no "updated by" moving the definition
of the term "version support" from one of its sections to another section.

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

Re: Last Call: (IPv6Support Required for all IP-capable nodes) to Proposed Standard

[t.petch]

I find this document utterly bizarre and think it would seriously damage the
Internet to publish it.

The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is
fine, the sort of statement that the IAB should make, or have made, as an RFC or
in some other form.

But this I-D claims
" Updates [RFC1122] to clarify that this document, especially in
   section 3, primarily discusses IPv4 where it uses the more generic
   term "IP" and is no longer a complete definition of "IP" or the
   Internet Protocol suite by itself.  "

IPv4 is a phenomenal success, and RFC1122 is a key part of that.  IPv4 was a
confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
through the cruft and rendered it usable.  IPv6 desparately needs an equivalent
to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is
never going to be it, but claiming that this I-D provides an update to RFC1122,
coupled
with its title, gives the message that there is not going to be such an I-D;
IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
success of IPv4).

Bin it.

Tom Petch


- Original Message -

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