NOMS 2014 Call for Papers

[Thomas Nadeau]

http://noms2014.ieee-noms.org/content/call-experience-session-papers

http://www.ieee-noms.org/

NOMS 2014 will be next year's IEEE flagship conference in the area of 
management of networked systems and services. The symposium will include an 
Experience Session program. Experience Sessions complement the Technical 
Sessions with contributions that emphasize practical experiences and lessons 
learnt in applying, implementing, and deploying management technology. They 
will focus on aspects such as real-world deployment scenarios, experiences with 
the management of new services and technology, industrial applications of 
management technology, implementation experiences, and organizational 
considerations. Experience sessions are particularly aimed at decision makers 
and experts from industry.
New this year and for the first time at NOMS, the best Experience Paper will be 
recognized with an award.
 
Topics of interest 
NOMS 2014's theme is "Management in a Software Defined World". NOMS 2014 will 
place particular emphasis on Software Defined Networking and related 
technologies; submissions in those areas are particularly encouraged. Specific 
topics include but are not limited to the ones listed below. Please refer also 
to the general Call for Papers.
• Management case studies and best practices
• Issues and experiences with practical deployments
• Software Defined Networks and enabling technologies
• Open source SDN frameworks, Open Daylight
• Experiences with OpenFlow deployments
• Orchestration and SDN controllers
• Network Function Virtualization implementations
• Data center automation
• Management of cloud
• Cloud service assurance
• Big Data analytics in management
• Management of virtualized environments
• OSS/BSS development
• Virtualization of operation centers and help desks
• Organizational aspects of IT service management
• IT governance
• Service engineering and operational challenges
• Management of emerging networks and services
• Green management and managing energy efficiency
• Smart buildings, industrial automation and management
• Experiences with autonomic networking and self-management
• Application of machine learning and data mining to management
• Advances in standardization
• Management information models
• Event correlation, diagnostics, fault, performance management
• Billing and accounting models and service level management
• Business alignment of IT service management
• Experiences with Call Home frameworks
• Managed service provider issues
• Service delivery and service assurance
• Experiences with process engineering and frameworks (ITIL, eTOM)
• Other topics in network and service operations and management

Re: When to adopt a WG I-D

[Thomas Nadeau]

Nicely written, largely stating what might be obvious for many, but 
still nice to see it in black and white.  

A few comments/suggestions:

1) Section 3.  Authors/Editors


I suggest that you suggest that WG (co)chair(s) add an editor that is 
unrelated to the draft, but that they trust who has good editing skills. As we 
all well know, that is half the battle for getting a draft successfully across 
the finish line and to the IESG. How many times has the IESG seen drafts that 
are not up to snuff in some (editorially-related) manner?  This person might 
also keep the draft's trajectory motivated in the forward progress direction.  
Finally, in cases where a draft is controversial, this //might// aid in 
diffusing any electric situations. 

2) Section 5.2.  Competing Drafts  states:

   Engineering for interesting topics often produces competing,
   interesting proposals.

I suggest replacing "interesting proposals" with just "competing 
proposals"

I'd also put a reference here to the point I made above.

3) A little further in this section, I suggesting amending the text a 
bit from:

Sometimes,
   multiple versions are formally published, absent consensus among the
   alternatives.

to something like:

Sometimes, multiple versions are formally published, absent consensus 
among the
   alternatives. In this way, marketplace economics and preferences are allowed 
to weigh-in on the relevancy of one approach versus the other(s).   In these 
cases, the working group should be prepared to revisit the drafts later once a 
clear preference in the marketplace exists. At this time the working group 
should be prepared to amend, narrow or delete the competing approaches as 
necessary, in order to clarify the multiple approaches to as narrow a selection 
of options as possible once the approaches are ready for Proposed Standard 
status.

4) There is also no mention of functioning and interoperability of 
implementations, and hence no reference to the "working code" part of the 
mantra. I think it is important to provide some guidance in this regard during 
all phases of the document's states.  For example, two competing approaches, 
but one with running and demonstrable interoperating code might cause a WG to 
err in that direction rather than having competing approaches just because a 
second one was dreamt up at the last minute for political reasons.

--Tom


> Hi,
> 
> Dave Crocker and I have this little draft [1] discussing the process and 
> considerations for creating formal working group drafts that are targeted for 
> publication.
> 
> We believe that this may help clarify some of the issues and concerns 
> associated with this part of the process. We are targeting this as 
> Informational (i.e. commentary on existing process, not new normative 
> definition of process) and would like your input.
> 
> What is not clear?
> What have we got wrong?
> How should we resolve the remaining editor notes?
> 
> Thanks,
> Adrian
> (per pro Dave)
> 
> [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
> 
> 
> 

Re: Meeting "lounges" at IETF meetings

[Thomas Nadeau]

I agree with randy. I've never had an issue finding a place to huddle/meet when 
necessary at an ietf meeting venue. between the hallways, bar, etc I'm not sure 
what the fuss is all about.

Tom 



On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:

>>> i have no need to micro-manage the secretariat.
>> seems to happen a lot around here...
> 
> symptom of too much free time on hands
> 
> randy
> 

Re: Basic ietf process question ...

[Thomas Nadeau]

I am discussing this very topic in the Ops meeting today at 3. Please 
come by to discuss.

--Tom


On Aug 2, 2012:9:25 AM, at 9:25 AM, Robert Raszuk  wrote:

> All,
> 
> IETF documents have number of mandatory sections .. IANA Actions, Security 
> Considerations, Refs, etc ...
> 
> Does anyone have a good reason why any new protocol definition or enhancement 
> does not have a build in mandatory "XML schema" section which would allow to 
> actually use such standards based enhancement in vendor agnostic way ?
> 
> There is a lot of talk about reinventing APIs, building network wide OS 
> platform, delivering SDNs (whatever it means at any point of time for one) 
> ... but how about we start with something very basic yet IMHO necessary to 
> slowly begin thinking of network as one plane.
> 
> I understand that historically we had/still have SNMP however I have never 
> seen this being mandatory section of any standards track document. Usually 
> SNMP comes 5 years behind (if at all) making it obsolete by design.
> 
> NETCONF is great and very flexible communication channel for provisioning. 
> However it is sufficient to just look at number of ops lists to see that 
> those who tried to use it quickly abandoned their efforts due to complete 
> lack of XML schema from each vendor they happen to use or complete mismatch 
> of vendor to vendor XML interpretation.
> 
> And while perhaps this is obvious I do not think that any new single effort 
> will address this. This has to be an atomic and integral part of each WG's 
> document.
> 
> Looking forward for insightful comments ...
> 
> Best,
> R.
> 
> 
> 

bits-n-bites: Exhibitors and product vendors hawking wares at an IETF meeting?

[Thomas Nadeau]

Has the IETF morphed into a conference/convention?

http://www.ietf.org/meeting/84/bits-n-bites.html

Re: Colloquial language [Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

[Thomas Nadeau]

On May 31, 2012:6:36 PM, at 6:36 PM, Ben Niven-Jenkins wrote:

> 
> On 31 May 2012, at 09:16, Ole Jacobsen wrote:
>> Sounds like a difficult thing to do with any kind of predictable or 
>> measurable outcome, although it might be fun to ask the Brits if they
>> understand everything the Americans are saying and vice versa :-)
> 
> I don't really have any issues understanding American English but I'm 
> regularly gobsmacked by how many North Americans struggle to understand some 
> things that I say :-)

I can personally attest to that. *)

--Tom

Re: Future Handling of Blue Sheets

[Thomas Nadeau]

I agree with you. I've always been puzzled as to why anyone needs to 
know who specifically attended a meeting. What is that information used for 
later?  As far as I can, no one ever has gone back to associate email addresses 
with speakers at the mic, actual attendee lists or presentations or something.  
Isn't the point just to gauge how full the room was so that we can book an 
appropriately sized room for the next meeting?  If that is the case, then just 
having the chairs take a rough estimate of how many people attended (or even 
just state a percentage of occupied seats) should suffice, right?

--Tom



On Apr 23, 2012:1:13 AM, at 1:13 AM, Kireeti Kompella wrote:

> On Apr 23, 2012, at 0:05, "EXT - joe...@bogus.com"  wrote:
> 
> (quoting from RFC 2418)
> 
>> All working group sessions (including those held outside of the IETF
>> meetings) shall be reported by making minutes available.  These
>> minutes should include the agenda for the session, an account of the
>> discussion including any decisions made, and a list of attendees.
> 
> RFCs are not gospel. They can, and, in this instance, should, be changed: 
> either remove that last item, or stately explicitly that there is no 
> expectation of privacy at IETF meetings.  (I have a sinking feeling I know 
> which way that will go.)
> 
> Why shouldn't getting the list of a meeting's attendees require a subpoena?  
> The cost argument is bogus; equally, there are those who think going to a 
> judge for permission to wiretap is a waste of time and money.
> 
> Put the money you save on NOT installing RFID kit into a fund for handling 
> subpoenas (only half joking). 
> 
> Kireeti
> 
> PS: Yoav, regarding your remarks on street surveillance, from the IETF Note 
> Well:
> 
> "A participant in any IETF activity acknowledges that written, audio and 
> video records of meetings may be made and may be available to the public."
> 
> A camera over meeting room doorways is next.

Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard

[Thomas Nadeau]

After looking over this just now - and forgive me as I didn't realize 
it contained a reference to 5542 until now - it seems to me that rather that 
including this in the RFC as "an update to RFC5542", this be added as an errata 
entry to 5542.  It seems odd to me to note that the single sentence represented 
here "updates" the RFC version, when what it does is really clarify it based on 
the new behavior outlined in the redundancy-bit draft, and even then "clarify" 
is difficult to use since it is more of an example of such a case of a 
'dormant' interface.

--Tom


On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote:

> Ooops. Thank you for pointing this out Stewart. I will make the update and 
> publish a new revision.
> 
> Mustapha. 
> 
> -Original Message-
> From: Stewart Bryant [mailto:stbry...@cisco.com] 
> Sent: Wednesday, March 07, 2012 12:48 PM
> To: draft-ietf-pwe3-redundancy-...@tools.ietf.org
> Cc: ietf@ietf.org; p...@ietf.org
> Subject: Re: Last Call:  (Pseudowire 
> Preferential Forwarding Status Bit) to Proposed Standard
> 
> 
> Authors
> 
> There was on point that I notice that you did not address from the AD review 
> and so I am picking it up as a LC comment:
> 
> In section 10 you say:
> 
>"This document makes the following update to the PwOperStatusTC
>textual convention in RFC5542 [8]: "
> 
> This update should be recorded in the metadata (top left front page) and it 
> is usual to put a one line note in the abstract.
> 
> Stewart
> 
> 
> 
> On 07/03/2012 17:00, The IESG wrote:
>> The IESG has received a request from the Pseudowire Emulation Edge to 
>> Edge WG (pwe3) to consider the following document:
>> - 'Pseudowire Preferential Forwarding Status Bit'
>> 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 2012-03-21. 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
>> 
>> 
>>This document describes a mechanism for standby status signaling of
>>redundant pseudowires (PWs) between their termination points. A set
>>of redundant PWs is configured between provider edge (PE) nodes in
>>single-segment pseudowire (SS-PW) applications, or between
>>terminating provider edge (T-PE) nodes in multi-segment pseudowire
>>(MS-PW) applications.
>> 
>>In order for the PE/T-PE nodes to indicate the preferred PW to use
>>for forwarding PW packets to one another, a new status bit is needed
>>to indicate a preferential forwarding status of Active or Standby for
>>each PW in a redundant set.
>> 
>>In addition, a second status bit is defined to allow peer PE nodes to
>>coordinate a switchover operation of the PW.
>> 
>> 
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> 
> 
> 
> --
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> ___
> pwe3 mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 

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

Re: Furthering discussions about BCP79 sanctions

[Thomas Nadeau]

I agree with Adrian. Individuals come to the IETF, not companies. Sure 
they are employed by companies, but they also have to follow the rules stated 
in BCP79.   I am really tired of the myriad of excuses people have given in the 
past about why they have not been able to comply. Its a really, really simple 
thing to read and understand the rules about the IETF's IPR policy BEFORE you 
submit a draft (or speak at a meeting), and WG chairs go out of their way to 
give people a number of warnings and reminders about this.  If after all of 
that you disagree, then go home.

--Tom



> Todd,
> 
> You may or may not be right about whether an individual can make a decision to
> disclose. In my experience they often can't, but do have the power to
> request/implore their employer to disclose.
> 
> On the other hand, they *do* have the power to not participate.
> 
> BCP79 offers this choice and I make no comment about which is preferable.
> However, it is clear from BCP79 that individuals have the choice and the
> responsibility to choose.
> 
> Thanks,
> Adrian
> 
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of todd
>> glassey
>> Sent: 14 February 2012 17:43
>> To: ietf@ietf.org
>> Subject: Re: Furthering discussions about BCP79 sanctions
>> 
>> On 2/12/2012 10:12 AM, Adrian Farrel wrote:
>>> Hi SM,
>> 
>> So isnt the real issue that of informed consent? If you dont know that
>> someone else has already existing work is it their fault for not telling
>> the IETF?
>> 
>> If so then there would also need to be some form of process identical to
>> this for verifying that the people participating hold legal power of
>> attorney pertaining to that work for their sponsors, or they cannot make
>> any 'management decisions' pertaining to any project.
>> 
>> The misunderstanding in the IETF BCP78 and BCP79 documents is that
>> one-size fits all for IETF participants. It simply cannot - In fact many
>> participants are there to work on processes and efforts for their
>> sponsors who have no legal power of attorney for their sponsors what so
>> ever. This is part of the myriad of misrepresentations that the IETF and
>> its parent ISOC are still trying to get the rest of the world to swallow
>> IMHO.
>> 
>> Todd
>> 
>>> 
> There has been some discussion on this list about
> draft-farrresnickel-ipr-sanctions-00.  Thanks for the input.
> 
> The conversation seems to be partitioned into:
> - discussion of sanctions and how to apply them
> - discussion of measures that can be taken to
>  help people to adhere to BCP79
 
 The following messages are about the "help people":
 
 http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html
 http://www.ietf.org/mail-archive/web/marf/current/msg02081.html
>>> 
>>> Yes. I've been watching those threads, and I think that some other WGs are
>>> thinking of following similar procedures.
>>> 
> Furthermore, there is some debate about who should/can be responsible
>> for
> applying sanctions.
>>> 
>>> [snip]
>>> 
 In Appendix A:
 
  "-  Does the large number of patents that the individual has authored
  provide any level of excuse for failing to notice that one of
  their patents covered the IETF work?"
 
 That should be "the individual has invented".
>>> 
>>> Yes.
>>> 
 I suggest removing the above as prolific inventors should pay more
 attention to BCP 79.
>>> 
>>> I'm inclined to agree with you.
>>> 
>>> Others feel that there may be some mitigation in this case.
>>> 
>>> By listing the point, we are giving the WG chairs the opportunity to
> consider
>>> it. They may deduce that it provides an excuse, no excuse, or exacerbates
> the
>>> case.
>>> 
 Section 6.1.2 of BCP 79 is about an IETF Participant's IPR in
 Contributions by others.   Should sanctions be considered if the
 individual participates and does not disclose?
>>> 
>>> Yes. That is certainly my intention in this document. All violations of BCP
> 79
>>> are cause to consider sanctions. The severity of the case may be judged by
>> many
>>> factors, and I suppose that the level of "participation" may be one of these
>>> factors. I am hoping that Section 2.1 makes the first point clear, and
> Appendix
>>> A the second point.
>>> 
>>> Cheers,
>>> Adrian
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>> 
>> 
>> 
>> --
>> Todd S. Glassey
>> This is from my personal email account and any materials from this
>> account come with personal disclaimers.
>> 
>> Further I OPT OUT of any and all commercial emailings.
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf

Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard

[Thomas Nadeau]

Agree %100.


On Jan 25, 2012, at 4:50 PM, Adrian Farrel wrote:

> Please also see US patent 20090204681 visible at  
> http://ip.com/patapp/US20090204681
>  
> In my opinion, this second last call should be suspended until this 
> significant breach of the IETF's IPR policy set out in BCP79 has been 
> resolved.
>  
> While it is important to find out what the IETF community's view of this 
> situation is, there are two questions:
>  
> 1. What does the WG think about the I-D being IPR encumbered and do they want 
> to develop an alternate solution that is not encumbered?
>  
> 2. How will the IETF handle the breach of IPR policy?
>  
> I believe the document should be returned to the working group who are the 
> main victims of the disruptive behaviour by the author.
>  
> Thanks,
> Adrian
>  
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adam 
> Roach
> Sent: 25 January 2012 21:36
> To: ietf@ietf.org
> Cc: si...@ietf.org; The IESG; IETF-Announce
> Subject: Re: Second Last Call:  
> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
>  
> Just to make sure I understand the sequence of events:
> August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for 
> SIEVE notifications. The inventor is listed as a single Huawei employee.
> August 30, 2007: That same Huawei employee and two additional authors publish 
> an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for 
> SIEVE notifications.
> September 2007 - September 2011: The SIEVE working group discusses and 
> improves the IETF draft.
> October 6, 2011: The IESG approves the IETF draft for publication as an RFC.
> December 14th, 2011: Huawei files an IPR disclosure with the IETF informing 
> it of patent CN 200710076523.4
> 
> Is that correct? Am I leaving anything out?
> 
> /a
> 
> 
> On 1/25/12 2:17 PM, The IESG wrote:
>  
> The IESG has received a request from the Sieve Mail Filtering Language WG
> (sieve) to consider the following document:
> - 'Sieve Notification Mechanism: SIP MESSAGE'
>as a Proposed Standard
>  
> Last calls were earlier issued on version -05 of this document and this
> document was approved by the IESG on 2011-10-06. Subsequently,
> an IPR disclosure statement for this draft was submitted.
> This Second Last Call is intended to determine whether the community
> is still comfortable with publication of this document in light of the IPR 
> statement.
> The relevant IPR statement is available at:
>  
> https://datatracker.ietf.org/ipr/1658/
>  
> 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 2012-02-08. 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
>  
>  
>This document describes a profile of the Sieve extension for
>notifications, to allow notifications to be sent over SIP MESSAGE.
>  
>  
>  
>  
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/
>  
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/
>  
>  
> The following IPR Declarations may be related to this I-D:
>  
>http://datatracker.ietf.org/ipr/1658/
>  
>  
>  
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>  
> ___
> 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: Questions about draft-betts-itu-oam-ach-code-point

[Thomas Nadeau]

On Jan 12, 2012, at 3:18 PM, John E Drake wrote:

> Snipped, comments inline.
> 
> 3. There seems to be quite a feeling on the mailing lists that this document
> should be run through the MPLS working group. The write-up makes a case for
> progressing it as AD sponsored. As far as I can see, the main assertions to
> answer are as follows. Do you have a view on these points before I make a
> decision on what to do?
> 
> a. This is a proposal to use an MPLS code point and so is part of MPLS by
> definition.
> 
> b. The type of network being managed by the OAM described in G.8113.1 is an 
> MPLS
> network. Therefore, this is clearly relevant to the MPLS working .
> 
> Do you object to this going through the MPLS on principle, or were you just
> hoping to save the WG the work? If the latter, and if the WG wants to look at
> the draft, the easiest approach seems to be to redirect the work to the 
> working
> group.
> 
> [MB]  G.8113.1 supports a subset of the functions defined in 
> draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March 2009, 
> the draft was presented at several meetings in 2009 and early 2010 and had 
> extensive discussion on the MPLS mailing list.  However, the MPLS WG have, by 
> rough consensus, adopted a different approach.  Therefore, further review by 
> the MPLS WG is of little value. 
> 
> [JD]   Um, I don’t think so. 
> 
> Since, as you state above, G.8113.1 is  effectively draft-bhh and since 
> draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests 
> a code point for G.8113.1, is basically an attempt to subvert the decision by 
> the MPLS WG to reject draft-bhh by attempting to bypass the WG with an 
> individual submission. 
> 
> So, I think it  is clear that your draft belongs in the MPLS WG. 
> 
> Incidentally, the MPLS/GMPLS change process was put in place in reaction to 
> the publication of another individual submission, RFC3474, which was 
> completely non-interoperable with standard RSVP, a surprisingly similar 
> situation.
> 

Well said John. I couldn't have put it any better myself, and so agree 
with that statement %100.

--Tom


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

Re: primary Paris hotel booking

[Thomas Nadeau]

I agree. In addition to that the pre-pay situation can be a major PITA 
for expensing purposes.  We should add "normal" booking procedures to the hotel 
requirements list as well.

--Tom


On Jan 3, 2012, at 11:52 AM, George, Wes wrote:

> Happy New Year, it's time for our triannual hotel complaint thread.
> I hate to do it, but I think that there are people who haven't looked at this 
> yet, and I'm hoping that we can perhaps rectify it before the majority of 
> folks try to book:
> 
> "Instructions for making reservations at Hotel Concorde:
> Please fill out the reservations form and fax it directly to the hotel at: 
> +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com"
> 
> It's 2012, but the IETF and this hotel chain expects us to book reservations 
> at the main conference hotel by (international) FAX or by *emailing* a form 
> which includes a credit card number so that the hotel can hold the room and 
> implement its relatively bizarre prepay/anti-cancellation policy.
> Would it be trolling to ask whether anyone verified that "cmasson" has 
> support for PGP encrypted-email and a proper method of securely storing (and 
> then destroying after use) the several hundred credit card numbers they are 
> about to receive?
> 
> What person or rate code should we ask for when booking our rooms over the 
> phone? (hey if I'm going old school, I'm doing it all the way!) Though, given 
> the above, I'm relatively worried that my credit card number will simply end 
> up on an unprotected spreadsheet on a PC somewhere in their office even if I 
> call to book.
> 
> More practically, the hotel blocks at the primary hotel typically fill up 
> quite fast once registration is opened, especially since the overflow hotel 
> is actually more expensive than the primary. Does the hotel fax/call us back 
> to tell us that they have no more rooms available for our requested dates, or 
> is the block open-ended such that they will keep selling rooms in it until 
> the cutoff regardless of the number?
> 
> Evidently "ability to book group rate rooms online" is something that should 
> be added to our list of hotel requirements. I'm stunned that it's not there 
> already.
> 
> 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
> 

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

Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

[Thomas Nadeau]

I disagree with the document shepherd's evaluation of this document. 
This document sets out to 
standardize an additional code point to support a type of OAM for MPLS, and as 
such the MPLS WG must 
review the document for technical correctness.  As far as I understand things, 
all MPLS documents that have 
requested ACH code points to-date have been on the standards track with MPLS 
expert WG review, and so this 
one should as well.

--Tom


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

Re: Requirement to go to meetings

[Thomas Nadeau]

> At 05:52 24-10-2011, Marshall Eubanks wrote:
>> As jabber scribe, I view part of my responsibility as relaying questions 
>> asked on jabber (if no one else is doing so). For groups that have 
>> secretaries, I suggest that that be part of the secretary's responsibilities.
> 
> The secretary is busy taking minutes.  That doesn't mean that the secretary 
> cannot draw attention if someone is asking a question on Jabber.  The audio 
> recording is a handy supplement when the speaker cannot be identified or to 
> cross-check the details.

In my experience that unfortunately happens about %10 of the time.  We 
need some way for remote participants to virtually stand in the mic queue so 
they get called upon and allowed to not only ask a question, but to follow-up - 
especially if the presenter needs clarification on the question.

> As for remote participation, if you do not know anyone in the room you are 
> going to be ignored.  That's an IETF feature that also applies for people who 
> attend meetings.  There are little things that can help remote participants 
> follow what is going on.  Melinda Shore mentioned some of them.  Most of the 
> fixes are non-technical.

Jabber/etc... are really bubblegum and bailing wire solutions.  I have 
been forced to skip meetings in the past due to budget issues, and can tell you 
that relying on others to proxy for you just doesn't work. Despite knowing 
someone in the room, you are assuming they are not busy trying to work 
themselves either participating in the meeting, writing documents, or whatever. 
 I've tried Skyping into meetings, jabber, whatever and it just doesn't work 
well because the people that ultimately must speak for you often can't.  Also, 
you assume people know someone well enough to ask for them; which is asking a 
lot especially for new people.

The best approach I've witnessed (and used many times) is WebEx where 
you can explicitly request to ask a question by virtually raising your hand, 
and then when the chair recognizes you, you can ask your own question. You can 
then interact with the presenter - and if the chairs are being sophisticated, 
they could project your face on a screen.  You can also use this mechanism as a 
means when gauging consensus where the chair(s) ask for a feeling of the room 
and for people to raise their hands.   

--Tom



> 
> If you do not go to meetings, it's unlikely that you will be able to follow 
> the BoF you are interested in.  There may be times when decisions are taken 
> during a meeting.  It is not worth the nit-picking if the outcome won't 
> change.
> 
> 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

Re: Requirement to go to meetings

[Thomas Nadeau]

On Oct 24, 2011, at 8:37 AM, Dave CROCKER wrote:

> 
> 
> On 10/24/2011 4:09 AM, Peter Saint-Andre wrote:
>>> It's really not that big a deal.  Make sure that audio is working,
>>> that there's a Jabber scribe/Jabber room watcher
> ...
>> I have a concrete suggestion for WG chairs: don't ask for a "Jabber
>> scribe" (which makes it sound as if the hapless volunteer needs to type
>> everything that's said into the chatroom) but instead ask for someone to
>> relay comments from the chatroom to the mic.
> 
> 
> Basic question:  what has been the claimed purpose for doing jabber scribing?
> 
> I thought it was a means of produce raw minutes.  A side -- and sometimes 
> extremely valuable -- benefit is as a relatively real-time alternative source 
> of information about what is being spoken; this can be quite helpful for 
> participants who are not native English speakers.
> 
> If neither of these purposes are worth the effort, then your suggestion 
> sounds dandy.  If either is sufficiently valuable, then my question is why 
> your groups haven't needed them.  (I'm expecting the answer to be that your 
> groups didn't feel the need; so my real question is why not?)

The problem with Jabber is that it has become an apparently replacement 
for audio/video conversation/Q&A at WG meetings for remote participants.   I 
find the jabber feed to be relatively useless at meetings for this purpose as 
the chairs do not always notice questions. Using something like WebEx is far 
more useful, and I'd suggest making it mandatory for all WG meetings in the 
near future to better facilitate remote participants.

--Tom


> 
> d/
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> ___
> 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

Software Defined Networks (SDN) BoF in Taipei

[Thomas Nadeau]

I wanted to pass on some information regarding a BoF that is planned 
for Taipei that is relevant to 
participants of this mailing list/WG area.  

The IAB and IESG met today to discuss BoFs for Taipei and agreed that 
we will hold a BoF
SDN with a goal of "discussing the technology and identifying work items". The 
BoF is nominally 
in the Routing Area, but we expect considerable involvement from the OPS Area 
as well. 

The following is a link to the drafts and other documentation around 
the SDN effort
including some presentations, and a link to join the BoF mailing list. 

http://trac.tools.ietf.org/bof/trac/

We encourage you to join the list, review the materials and participate 
on the mailing
list as well as come to the BoF if you have an interest in this work.

--Tom


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

Re: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Thomas Nadeau]

On Sep 29, 2011, at 3:52 PM, Brian E Carpenter wrote:

> Scott,
> 
> On 2011-09-30 05:30, Scott O Bradner wrote:
>> I'm having a hard time understanding just what this document is trying to do
>> 
>> I understand from the title that it is supposed to be telling the reader why 
>> a single OAM 
>> solution is a good idea for MPLS-TP
>> 
>> if that is the case I'm not all that sure what the purpose of sections 4 and 
>> 5 are for - they seem
>> to be exploring land outside the reservation - how about just addressing the 
>> topic in the title?
> 
> That goes a bit further than my own suggestion of moving them to
> an Appendix, but they are indeed off the main track of the argument.
> You're probably right; it would be more succinct and equally
> powerful without them.

I personally liked your idea of moving to an appendix.  That keeps them 
in black and white and in a place that can be referenced.

--Tom


> I think we all know that competing standards are a bad thing,
> without
> having to get the historical details of SDH vs SONET right. Whatever
> good work was done to fix the SDH/SONET case, the fact is that users were
> seriously inconvenienced, exactly as they were earlier by the difference
> between E1 and T1. [Anecdote about the first T1 link carrying IP across
> the Atlantic deleted.]
> 
>   Brian
> ___
> 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: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Thomas Nadeau]

A few more thoughts on this thread.

> All,
> 
> I propose to completely remove section 5 of this draft.
> 
> The reason:
> 
> The IETF should *NOT* document any comment on any "multiple standards"
> developed by other SDOs which are outside of the IETF's scope.
> 
> Especially standards like like SONET/SDH, CDMA/GSM.
> 
> The current text reflects the author's impressions, and since I don't
> believe that the authors were involved in the debates when these
> standards were developed, they *DO NOT KNOW ENOUGH* to comment
> authoritatively on them.

Why do you suddenly think that it is important for only people with 
knowledge of a topic to contribute to standards? Where does that leave the 
ITU-T's input on MPLS?  I can give you many examples of where people who had no 
qualification as "experts" in a particular field have contributed to standards, 
but I will refrain from doing so so as to not "offend other SDOs" as you say 
below. 8)

> The IETF should refrain from documenting things that might offend
> other SDOs concerning standards issues in which IETF was or is not
> involved.

Since when does offending other SDOs become a concern of any other SDO? 
Along these lines, let us take the flip-side of that example you give and ask 
ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other 
SDOs for that matter) and why there was not a concern of offending when those 
were made?

--Tom



> 
> Best regards, Huub.
> ___
> 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: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Thomas Nadeau]

On Sep 29, 2011, at 1:06 AM, Huub van Helvoort wrote:

> All,
> 
> I propose to completely remove section 5 of this draft.
> 
> The reason:
> 
> The IETF should *NOT* document any comment on any "multiple standards"
> developed by other SDOs which are outside of the IETF's scope.
> 
> Especially standards like like SONET/SDH, CDMA/GSM.
> 
> The current text reflects the author's impressions, and since I don't
> believe that the authors were involved in the debates when these
> standards were developed, they *DO NOT KNOW ENOUGH* to comment
> authoritatively on them.

Isn't that why this draft is targeted as an *individual and 
informational* draft?  Since that is the case, I don't see how your point is 
relevant to the document at hand.

> The IETF should refrain from documenting things that might offend
> other SDOs concerning standards issues in which IETF was or is not
> involved.

That is your opinion. However, please observe that other SDOs document 
and cross-reference each others' works all the time often adding their "2 
cents".  For example, take what the BBF does with many IETF standards.

--Tom




> 
> Best regards, Huub.
> ___
> 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: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC

[Thomas Nadeau]

I agree. Historic seems go be the way to go with this document.

Sent from my iPad

On Sep 13, 2011, at 3:16 PM, Luca Martini  wrote:

> On 09/13/11 10:03, Alexander Vainshtein wrote:
>> Luca, and all,
>> 
>> I concur with Andy's opinion that the reference to RFC 4447 must become 
>> Normative (this will not delay the publication is  too often the case:-).
>> 
>> As for Informational vs. Historical, I think that Informational is more 
>> appropriate because, AFAIK, the technique defined in draft-kompella is not 
>> just a documenting an existing solution - it describes is THE ONLY deployed 
>> solution for the problem. (If this statement happens to be factually 
>> incorrect, I would be happy to learn about the deployed alternatives.)
> no, there are several ( I think 3 ) implementations of the
> l2vpn-singalling standards track document also known as rfc6074.
> There are several deployments of rfc6074.
> 
> As 10 years ago we had several deployments of "draft-martini" which over
> time are being updated to rfc4447 , there are some deployments of the
> solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still
> think that an historical RFC would fit this solution , unless we plan on
> expanding it , and pursuing new enhancements to it.
> 
> Luca
> 
> 
>> Regards,
>> Sasha
>> 
>>> -Original Message-
>>> From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of 
>>> Luca
>>> Martini
>>> Sent: Tuesday, September 13, 2011 6:24 PM
>>> To: Andrew G. Malis
>>> Cc: l2...@ietf.org; pwe3; IETF Discussion
>>> Subject: Re: Last Call:  (Layer 2 Virtual
>>> Private Networks Using BGP for Auto-discovery and Signaling) to 
>>> Informational
>>> RFC
>>> 
>>> I concurr with Andy.
>>> Given that the  WG has made a decision on which control plane technology
>>> is the standard track technology we should have a statement in this
>>> document pointing to the standard track rfc4447 so it is clear to anyone
>>> reading the document.
>>> In the same way we published the draft-martini documents as historical
>>> ee should publish this document as historical rfc, to document existing
>>> implementations.
>>> 
>>> Luca
>>> 
>>> On 09/01/11 05:42, Andrew G. Malis wrote:
 Speaking as an individual, the solution in this draft has been has
 been operationally deployed in a number of service provider networks,
 and it should be documented in an informational RFC.
 
 Speaking as PWE3 co-chair, I would be happier if this draft required
 that routers that implement this solution also implement RFC 4447,
 that RFC 4447 be configured as the default mechanism for pseudowire
 signaling, and that RFC 4447 was moved from an informational to a
 normative reference. In practice, I know that routers that implement
 this also do implement RFC 4447, but I would like to see it in the RFC
 as well.
 
 Thanks,
 Andy
 
Subject:Last Call: (Layer 2 Virtual Private Networks Using BGP
for Auto-discovery and Signaling) to Informational RFC
Date:Tue, 30 Aug 2011 10:50:05 -0700
From:The IESG 

Reply-To:ietf@ietf.org 
To:IETF-Announce 

 
 
 
The IESG has received a request from an individual submitter to consider
the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
   Signaling'
   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-27.
>>> 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
 
 
   Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
   circuits have been around a long time; more recently, Ethernet VPNs,
   including Virtual Private LAN Service, have become popular.
   Traditional L2VPNs often required a separate Service Provider
   infrastructure for each type, and yet another for the Internet and IP
   VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
   presents a new approach to the problem of offering L2VPN services
   where the L2VPN customer's experience is virtually identical to that
   offered by traditional Layer 2 VPNs, but such that a Service Provider
   can maintain a single network for L2VPNs, IP VPNs and the Internet,
   as well as a common provisioning methodology for all services.
 
 
 
 
The file can be obtained via
http://datatracker.ietf.org/doc/

Re: Hyatt Taipei cancellation policy?

[Thomas Nadeau]

On Aug 24, 2011, at 4:33 PM, Alia Atlas wrote:

> On Wed, Aug 24, 2011 at 4:30 PM, Dave CROCKER  wrote:
> 
> 
> On 8/24/2011 1:27 PM, Sam Hartman wrote:
> Can you start by backing up the assertion  that the community has
> vigrously expressed a preference for interesting venues?
> I may just need a new IETF community:-)
> 
> 
> gosh, I hadn't thought that that was less than obvious, given the vote for 
> quebec and many, many comments about venue choice over the years.
> 
> I'm one who really liked Minneapolis - we had excellent meeting space, places 
> to run into each other, reasonable food access, and a clueful hotel.
> 
> Is it interesting to go to new places?  Sure and if I'm lucky I might get a 
> morning or afternoon to look around.  Would I be perfectly happy going to the 
> same 2-3 places every year?  Absolutely.

I am with you on that. I do not attend IETFs as a vacation and 
sight-seeing opportunity.

--Tom


> 
> Alia 
> ___
> 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?

[Thomas Nadeau]

But surely based on that block purchasing power we could negotiate more 
reasonable rates than $200+ night?

--Tom



On Aug 23, 2011, at 2:07 PM, Ole Jacobsen wrote:

> 
> You said:
> 
> "At root is that we are trying to negotiate a purchase at a discounted
> price without committing to buying any particular number of rooms,
> versus only a limited number of possible sellers."
> 
> When negotiating a group rate we actually ARE committing to buying a 
> certain number of rooms (the "room block"). There are certainly pros
> and cons with group rates. On the pro side: guaranteed rate (but not 
> necessarily the absolute lowest available at any time), included 
> benefits (breakfast, Internet, if applicable), free or subsidized
> meeting rooms where applicable. On the cons side is of course the
> cancellation policy (not that it has to be as onerous as this one).
> 
> Ole
> 
> 
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
> Skype: organdemo
> 
> 
> 

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

Re: Hyatt Taipei cancellation policy?

[Thomas Nadeau]

On Aug 23, 2011, at 10:24 AM, John C Klensin wrote:

> 
> 
> --On Tuesday, August 23, 2011 07:57 -0400 Thomas Nadeau
>  wrote:
> 
>>> 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.
>> 
>> I think we need to adopt a simple rule of thumb whereby we do
>> not book venues where room rates of less than $200 USD are
>> unavailable - sponsor or otherwise.
> 
> Tom, I'm usually not the one to leap to the defense of the IAOC
> on meeting costs, but I think we need to be very careful about
> such rules.  For many of us, total cost of meeting -- total
> hotel room costs (which may be different from quoted rate), air
> fares and other transport, days away from home, meals,
> registration fee (for this meeting, I notice what I think is is
> a new incentive to register at the last minute prior to the
> "early" cutoff), even the cost of beer for those who depend on
> it to lubricate conversations -- is far more important than the
> hotel bill alone.  In many cities, rooms quoted at USD 200 (or
> much less) are easy to find, but one can make up for it in taxi
> charges or Internet access surcharges.  Others may have
> different constraints -- I've worked with companies for whom
> transport to a meeting comes out of different accounts than
> being there and therefore counts either more or less.  And hotel
> (and other on-site) costs can fluctuate considerably as exchange
> rates change.
> 
> Of course, the difficulty of calculating total meeting costs is
> that each of us has different habits, comes from different
> locations, has different travel perferences, etc.  IAOC claims
> that they try to approximate that number and consider it.  I
> think they often get it wrong but acknowledge that it is
> probably impossible to get it right.

I agree that the overall cost of each meeting is what really counts.
HOWEVER, most of us work at companies which have rules for 
limits on specific charges (i.e.: hotel room rates).  Having room rates
(fees/taxes/etc...) that exceed about $200 usually gets people in 
trouble with their travel departments, not to mention the overall cost
of the meeting.  I think this was discussed at the last Plenary where
typical meeting venues in Asia were having very significantly higher
costs associated with meeting venues/hotels.

> So I'm opposed to a USD 200 (or any other number) firm limit on
> hotel rates.  At the same time, I continue to wish that the IAOC
> would be more open with the community about how these decisions
> are made and, in particular, how the tradeoffs between
> sponsorship (and hence lower costs to the IETF for meeting
> infrastructure and arrangements) and meetings costs to attendees
> are made... open enough that the community could give
> substantive guidance on the subject, guidance that I assume the
> IAOC would follow if it were coherent and plausible.

I am not advocating for any hard limit. I said "about $200".  I think
most people would agree that $210 or even $230 would be acceptable, 
whereas $300 is getting a bit silly.

> Being a little cynical, I do wonder if we would see a difference
> in meeting selection patterns if all IASA staff and IAOC members
> were required to stay in hotel or other rooms costing no more
> than, say, your USD 200 per night figure (including transport,
> if necessary, to and from the meeting site).  It might help to
> calibrate the pain level.  The idea is not realistic for a
> number of reasons, but might make an interesting
> thought-experiment.

Indeed. Budget is budget.

--Tom




> 
> john
> 
> 

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

Re: Hyatt Taipei cancellation policy?

[Thomas Nadeau]

On Aug 23, 2011, at 9:43 AM, Worley, Dale R (Dale) wrote:

>> From: Michael StJohns
>> 
>> 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.
> 
> Maastricht had particularly fierce cancellation rules.  I don't
> remember the details, but under some circumstances you could have to
> pay for the entire stay.

One would think that when the IETF negotiates the room block/fees, that 
this could be done as well. After all we are in many cases, booking a 
significant portion of the hotel in question in addition to its conference 
facilities.

--Tom



> 
> Dale
> ___
> 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?

[Thomas Nadeau]

On Aug 23, 2011, at 1:34 AM, John C Klensin  wrote:

> 
> 
> --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.

I think we need to adopt a simple rule of thumb whereby we do not book venues 
where room rates of less than $200 USD are unavailable - sponsor or otherwise.

Tom


> 
>   john
> 
> 
>   john
> 
> 
> ___
> 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: [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: A modest proposal for Friday meeting schedule

[Thomas Nadeau]

On Aug 2, 2011, at 7:48 AM, Adrian Farrel wrote:

>> BTW, has anyone noticed the trend of doing more and more on the Sunday and
>> Saturday *before* IETF week?
> 
> Very much so. 
> Workshops, joint meetings, design teams...
> In Prague, a good number of people started in Friday.
> 
> Nothing wrong with that, but it does put paid to the idea that the IETF is 4.5
> day meeting, and that squeezing it at one end will restrain it. 
> Toothpaste-like,
> squeezing the closing Friday will only cause more spillage on the opening
> Sunday.
> 
> OTOH, I have good reason to think that the application of more focus by WGs
> during their meetings *could* reduce the pressure on the whole schedule. Thus,
> the perennial thread on not presenting drafts at WG meetings would surely bear
> fruit.

Indeed. A few people were discussing this during one of the meetings 
last week where the agenda was packed to the gills, and the WG chairs were 
cutting off discussion after just 1 or 2 people at the mic.  We were all 
wondering why we spent any time allowing for the presentation and instead 
should have allowed the full 5/10 minute slot for discussions/debate.  Even 
better, what if we spent a whole 15 minutes discussing or debating?!

--Tom



> 
> Adrian
> 
> 
> ___
> 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: A modest proposal for Friday meeting schedule

[Thomas Nadeau]

On Aug 1, 2011, at 9:39 AM, John Leslie wrote:

> Thomas Nadeau  wrote:
>> On Jul 31, 2011, at 11:48 AM, Eric Burger wrote:
>>> On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote:
>>> 
>>>> Something like this:
>>>> 8:30-11:00 Session I
>>>> 11:15-12:15 Session II
>>>> 12:30-13:30 Session III
>>> 
>>> I really like it, as there are a bunch of post-IETF stuff, some of
>>> which starts in the afternoon and thus conflicts with the IETF.
>> 
>> I'd actually vote for NO meetings on Fridays...
> 
>   We have been trying to treat Friday as a "real" day for a year or so,
> and it's only partly working.
> 
>   For IETF81, I'd have to rate the Friday TSVWG and V6OPS an a success
> (though I was barely functional by then). Squeezing them into the
> Monday-Thursday schedule would have made for serious conflicts.
> 
>   We need some improved paradigms...
> 
>   For one, I suggest we take remote-participation _seriously_ for the
> Friday meetings. Many of us are waiting-for-Godot at airports on Friday,
> and could certainly wear a headphone/mike and watch our laptop screens.
> Meetecho seemed ready to manage that sort of thing. :^)

That may work, but it does require that someone be at the meeting venue 
while the rest sit in the airport.

--Tom


> 
> --
> John Leslie 
> ___
> 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: A modest proposal for Friday meeting schedule

[Thomas Nadeau]

I'd actually vote for NO meetings on Fridays. %90 of attendees fly home 
on Friday if at all possible, especially since most of us have flown in on 
Sunday.  Unless you are local to the meeting, it is a major hassle leaving 
after the meetings on Friday, especially if you are international, since you 
are unlikely to make your flight and then are forced to stay another night.  
This adds to the expenses of the trip, which most companies are now very 
sensitive to. This added day is especially evident if you are in some 
relatively obscure location as was last summer's meeting or the last one in 
Japan, that had no easy direct access to a major airport other than several 
hours of train/travel.  Blowing nearly 2 weekends in a row for each IETF 
meeting is not the way forward if you ask me. 8)

--Tom


On Jul 31, 2011, at 11:48 AM, Eric Burger wrote:

> I don't think I have seen a proposal like this before.  I really like it, as 
> there are a bunch of post-IETF stuff, some of which starts in the afternoon 
> and thus conflicts with the IETF. This fixes that problem, enables us to have 
> the same amount of meeting time, and potentially lets people get home a day 
> early.
> 
> On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote:
> 
>> Howdy,
>> First I'd like to thank the organizers for IETF-81 for another well-run 
>> meeting.  The logistics and coordination for such an event must be daunting, 
>> and I know we (the attendees) tend to focus on the negatives rather than the 
>> positives... but we really are thankful for all the time and effort put into 
>> it.  Thank you!
>> 
>> I would also like to propose a small change for future meetings.  On Friday, 
>> instead of having a 2.5 hour WG meeting, followed by a 1.5 hour lunch break, 
>> followed by 2 hours of WG meetings... perhaps we could just have 4.5 hours 
>> of WG meetings straight and also start a bit earlier?  
>> 
>> Something like this:
>> 8:30-11:00 Session I
>> 11:15-12:15 Session II
>> 12:30-13:30 Session III
>> End
>> 
>> That way the people who need to get to an airport get more time, or fewer of 
>> them have to miss WG meetings, etc.  And it would help reduce costs for 
>> attendees if they can avoid staying Friday night at the hotel.  And lunch at 
>> 13:30 doesn't seem unreasonable (to me).
>> 
>> I apologize if this has been brought up before.  I tried to find it from an 
>> old email thread for the "Experiment" at IETF-73 which added the Friday 
>> afternoon sessions, but did not see this proposal being suggested.
>> 
>> -hadriel
>> 
>> ___
>> 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

Re: [v6ops] 6to4v2 (as in ripv2)?

[Thomas Nadeau]

On Jul 27, 2011, at 7:31 AM, Mark Townsley  wrote:

> 
> On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
> 
>> 
>> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
>> 
>>> Since 6to4 is a transition mechanism it has no long term future *by 
>>> definition*. Even if someone chooses to design a v2, who is going to 
>>> implement it?
>> 
>> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. 
> 
> +1
> 
> - Mark

+2


> 
>> ___
>> v6ops mailing list
>> v6...@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> ___
> 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: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[Thomas Nadeau]

On Jul 8, 2011, at 3:15 AM,  wrote:

> Got to say I agree with Rui on much of what he says here.  And I absolutely 
> resonate with his point on the need for simplicity.  The reason OAM needs to 
> be as simple as possible is because it must be super reliablewe do not 
> want to consciously build in weaknesses, esp unnecessary ones this also 
> implies minimal config.  We could all do better on this.  For example:
> 
> -   Rui is dead right a CC function is fairly useless, we only need a CV 
> function...the ATM OAM in I.610 suffers from this problem (and few others 
> like AIS and the assumed use of request/response MLT to diagnose 
> leaking/mismerging traffic...request/response OAM won't work with 
> unidirectional defects).

While you are entitled to your opinion, I personally think there are 
enough requirements elsewhere to have both CC and CV functions.  But we 
digress. Are you actually asking that the CC functionality be removed from the 
draft or just making a general comment?

> -   all packet layer networks should not have an AIS OAM messagevery 
> obvious for the cl-ps mode of course.  The co-ps mode is also not like the 
> co-cs mode.  One has to consciously manufacture AIS messages and target them 
> to specific clients in the co-ps modewho may have taken action in their 
> own layer network and 'moved elsewhere' anyway, ie a total waste of time now. 
>  AIS is actually unnecessary wrt providing information anyway, it simply 
> represents an in-built weakness of just something else to go wrong which 
> itself will create problems.

What does that comment have to do with the actual draft in question?

> -   creating preconfigured TCM sublayers is just asking for trouble IMO.  
> It is far smarter to simply create a single end-end OAM CV (and when required 
> PM) flow and tap this off at intermediate nodes on the *rare* occasions one 
> wants to do.

Again, what does this have to do with the actual draft in question?

--tom




> 
> regards, Neil
> 
> This email contains BT information, which may be privileged or confidential.
> It's meant only for the individual(s) or entity named above. If you're not 
> the intended
> recipient, note that disclosing, copying, distributing or using this 
> information
> is prohibited. If you've received this email in error, please let me know 
> immediately
> on the email address above. Thank you.
> We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 180
> 
> 
> 
> 
> 
> 
> 
>> -Original Message-
>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
>> Rui Costa
>> Sent: 08 July 2011 01:15
>> To: David Allan I; Stewart Bryant
>> Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org
>> Subject: Re: [mpls] Last Call: 
>> (Proactive Connectivity Verification, Continuity Check and Remote
>> Defect indication for MPLS Transport Profile) to Proposed Standard
>> 
>> David,
>> 
>> Reading something, keeping it on record, without effect in the draft
>> and "ignoring comments" have IMHO similar outcomes. As author of the
>> draft you are free to do it. These standards have a great impact in our
>> work, so i'm also free to write what i did.
>> 
>> 
>> 
>> 
>> Stewart,
>> 
>> My technical concerns regarding this draft were expressed...
>> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i
>> believe);
>> ...in operators' meetings' that took place during ITU-T's Feb/2011
>> plenary meeting;
>> ...in a comparison session that took place during that same ITU-T
>> meeting.
>> Some:
>> 
>> CC/CV
>> I don't understand the need for 2 types of packets: a single type
>> allows CC; mismatching identifiers in the same CC packets allow CV.
>> Besides adding complexity, we whether always activate both or
>> potentiate undetected mismerges.
>> (BTW: can't understand how we propose one ACH codepoint to CC, another
>> for CV, [counting other drafts, another for frame loss ...] but don't
>> consider assigning 1 single ACH protocol identifier codepoint as
>> requested by ITU-T)
>> 
>> Uni P2P / P2MP
>> I can't see how BFD will support unidir and hence P2MP other than...
>> 
>> ...eliminating the session "state variable" (down, init, up), aiming
>> just the state variables we really need, bringing us to something
>> similar to 1731, eventually with other bits on the wire or...
>> ...using IP to create the reverse way, which we cannot assume per
>> requirements;
>> Will we create a complete different tool for that?
>> (BFD's B="bidirectional")
>> 
>> Provisioning list
>> This is an MPLS profile/subset (and i heard) achievable through a
>> particular configuration. So, i expect each draft-ietf-mpls-TP-* to
>> focus on that profile/configuration. However, i keep seeing references
>> f.i. to IP encapsulations unexpected under TP's OAM.
>> I don't thus understand what the 

Re: Has anyone found a hotel for Quebec City that isn't exorbitant?

[Thomas Nadeau]

BTW, I found that like with many previous IETF meetings, if you call 
your local travel department, they can often get far cheaper rates for the 
rooms at the hotel. For some reason, the IETF "negotiates" rates that seem to 
be MSRP.  For this one, for example, I got something like a %40 discount on the 
IETF rate.

--Tom


> But that was then and now is now 8->.  One could simply say "suck it up".
> 
> Sent from my iPhone
> 
> 
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>> Henk Uijterwaal
>> Sent: Sunday, June 19, 2011 6:55 PM
>> To: ietf@ietf.org
>> Subject: Re: Has anyone found a hotel for Quebec City that isn't
>> exorbitant?
>> 
>> On 19/06/2011 08:01, Glen Zorn wrote:
>>> On 6/18/2011 9:52 PM, Keith Moore wrote:
>>> 
 Frankly, I'm appalled at the prices and think it's highly
>> inappropriate for
 IETF to be meeting in venues where the "conference hotels" are so
 expensive.
>> 
>> May I point out that there has been a survey on the topic and the
>> community
>> expressed a clear preference for Quebec over other Canadian cities,
>> knowing
>> that travel would be longer and the number of cheap alternative hotels
>> smaller.
>> 
>> Henk
>> 
>> --
>> ---
>> ---
>> Henk Uijterwaal   Email: henk(at)uijterwaal.nl
>>  http://www.uijterwaal.nl
>>  Phone: +31.6.55861746
>> ---
>> ---
>> 
>> There appears to have been a collective retreat from reality that day.
>> (John Glanfield, on an engineering
>> project)
>> ___
>> 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

Re: one data point regarding native IPv6 support

[Thomas Nadeau]

Sadly this is more common than it should be these days. I've been 
begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME 
now have been subjected to as Verizon sold off FIOS/dsl in those areas to them 
a while back. I have "business" service from them with static IPs and the whole 
9 yards, and they still insist that I am mad when I call to ask for IPv6 siting 
the same reasons you are being given.

--Tom


> I just called my ISP to ask about availability of IPv6 at my home.
> 
> Me:  "I'm a current customer, and I'm just calling to ask if you support 
> Internet Protocol Version 6."
> 
> First person: "Yes, we do support Internet.  We support DSL at 3 megabits and 
> 6 megabits."
> 
> Me: "I understand that, but I'm asking about Internet Protocol version 6, 
> IPv6.  The Internet has been using IP version 4 since the early 1980s, but 
> that's running out.  IPv6 is the new version."
> 
> First person: "Let me transfer you to support."
> 
> Second person: "Hi, this is support.  How may I help you?"
> 
> Me: "I'm a current customer, and I'm just calling to ask if you support 
> Internet Protocol Version 6."
> 
> Second person: "IP version what?"
> 
> Me: "Internet protocol version 6".
> 
> Second person: "I have no idea.  Let me transfer you to someone else."
> 
> (places me on hold for 15 minutes)
> 
> Second person: "I'm sorry for the wait time.  I've been trying to find the 
> answer to your question, but nobody here seems to know anything about it.  
> We're trying to get in touch with people who run the network to ask them.   
> Can I get your number and call you back?"
> 
> Granted, this is just one ISP.  The other ISP that offers service in my area 
> put me on hold for an hour and a half *before anyone ever talked to me* when 
> I tried to get a quote from them, so I concluded that they wouldn't be a good 
> choice.  And these guys have been good about support in general.  They seem 
> to know their stuff, which is more than I can say for some ISPs I've dealt 
> with in the past.
> 
> I live in a well-settled urban area, three miles from the center of the city 
> (and sadly, four miles from my CO, which means my DSL circuit gets around 
> 380kbits/sec).  It's not a backwater, there's plenty of lit fiber running 
> through town.  But when the support people for a fairly well-established 
> telco haven't even heard of IPv6, it's hard to believe that it's going to be 
> available anytime soon.
> 
> Meanwhile, 6to4 continues to work just fine for me.
> 
> So please explain again why it isn't premature to discourage a valuable 
> transition mechanism?
> 
> Keith
> 
> ___
> 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