Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12

[joel jaeggli]

On Oct 13, 2013, at 7:32 AM, Abdussalam Baryun  
wrote:

> Yes, my comment meant that it is a reply to the review message that there may 
> be not clear definition from other participant point of view. Sorry my review 
> is still not complete, I will send it. Do you mean my reply is not right, if 
> I like to give a short comment before my full review.
> 
> AB
> 
> On Sunday, October 13, 2013, Adrian Farrel wrote:
> Hi,
> 
> I am having sever difficulty parsing all of the information from your comment.
> And currently cannot see anything actionable by the authors.
> 
> > The draft does not list ITU in abbreviation,
> 
> Loa has answered why this is not necessary.
> 
> You mean that IETF agrees to do that as per a RFC  passed or community 
> awareness. 
> 
> > there are many terminology not clear but more general definition.  I
> > prefer specific defining.
> 
> This comment gives us nothing to go on! Which terminology do you find not 
> clear
> but is a more general definition? And why is this a problem?
> 
> You cannot expect the authors to fix or even discuss something if you do not
> show them what you are talking about.
> I am talking about the draft in overall, I will do my review if time is 
> available.
> 

Insubstantial comments during the last call by someone who claims to have not 
reviewed the document are rather condescending. If you were the author what 
would you do with this "feedback"? 

Expectations of collegiality require a certain respect for common purpose, and 
the purpose of the last call is to surface remaining issues of substance, test 
for consensus and move on. (2418 section 8)

> > Also many times refers to references to define without mentioning
> > what was that definition,
> 
> What do you mean? Can you give an example and say how you think it should be?
> Will be shown in a full review message, this was a comment message, but 
> thanks for your advise 
> 
> > is that defined only in ITU and IETF cannot define its technology, or
> > is it agreeing on a joint definition so IETF is just following ITU in some
> > terms.
> 
> *This* document is seeking IETF consensus. If that consensus is reached all
> definitions will be IETF definitions. If those definitions originate in ITU-T
> documents, they are also ITU-T definitions. If ITU-T documents make normative
> reference to IETF documents that contain definitions, those definitions are
> ITU-T definitions.
> 
> Maybe I have missed the point of your comment.
> 
> The point is why do we need other organisation definitions, or why did the 
> author use those definitions, my point is any definition should relate to 
> internet technology not references of other org, we may use other definitions 
> for ours.
> 
> Adrian
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Montevideo statement

[joel jaeggli]

On Oct 9, 2013, at 9:02 AM, Tobias Gondrom  wrote:

> On 09/10/13 14:14, Ted Lemon wrote:
>> On Oct 9, 2013, at 6:45 AM, Tobias Gondrom 
>>  wrote:
>> 
>>> But I support SM's proposal that it would be good
>>> to do a few days comment period for such important statements in the
>>> future - if timing is not critical. There is no harm in a few days delay
>>> and getting input from the community.
>>> 
>> This is a nice theory, but the usual last call time at IETF is either two 
>> weeks or four weeks, not a few days, and that's for a good reason.  I think 
>> there is no way that a statement of the type we are discussing can ever 
>> represent IETF consensus unless we go through an actual consensus call.
>> 
>> So the real question here is, is it ever appropriate for the chair of the 
>> IAB or the chair of the IETF to sign a statement like this without getting 
>> consensus?   I think that's a good question, and I don't have a strong 
>> opinion on the answer.   But if the answer is that we need consensus, then 
>> we actually need to do a consensus call.
>> 
>> The only value I see in "a few days" would be an opportunity for 
>> wordsmithing—as someone pointed out, the current statement could be read as 
>> expressing concern that secrets were leaked, rather than concern about what 
>> was done in secret, and it would have been nice if that wording could have 
>> been corrected.   If that is what you were asking for, then that does make 
>> sense.
>> 
>> (thinking out loud...)
>> 
>> 
> 
> Yes, that is what is was thinking about. Probably wisdom of the crowds could 
> have helped with the wordsmithing part. 

I imagine that's exctly the part of course that they aren't interested in once 
they're hashed out a high-level statement (and have general agreement between 
the signatories ) is more input. 

It seems dramatically simpler to just make the satement as individuals who put 
their name on something.


> And in my view even some little feedback (3-7 days) is better than none. And 
> just to be clear: with such a short comment option, the goal is just comments 
> not to get a rough consensus. 
> 

We have a process for obtaining consensus. It takes a little while.

> All the best, Tobias
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Montevideo statement

[joel jaeggli]

On Oct 8, 2013, at 11:44 PM, Andrew Sullivan  wrote:

> Dear colleagues,
> 
> On Tue, Oct 08, 2013 at 10:55:08PM -0700, SM wrote:
>> This is the second time that the IAB has issued a statement
> 
> Speaking only (empahtically only) for myself, I quite strongly
> disagree.  The IAB has issued no statement in this case.
> 
> The text as posted is quite clear:
> 
> ---%<---cut here---
> 
> "The leaders of organizations … have met"
> […]
> Russ Housley, Chair
> Internet Architecture Board (IAB)
> 
> --->%---cut here---
> 
> That does not say that the IAB has issued a statement.  On the
> contrary, the IAB did not issue a statement.  I think the difference
> between some individuals issuing a statement in their capacity as
> chairs and CEOs and so on, and the body for which they are chair or
> CEO or so on issuing a similar statement, is an important one.  We
> ought to attend to it.
> 
> Please note that this message is not in any way a comment on such
> leadership meetings.  In addition, for the purposes of this discussion
> I refuse either to affirm or deny concurrence in the IAB chair's
> statement.  I merely request that we, all of us, attend to the difference
> between "the IAB Chair says" and "the IAB says".

It would be highly salubrious if in the future if things that look like open 
letters are simply signed by individuals listing their organizational 
role/affiliation rather than stating that leaders of the following 
organizations support this statement. There is  abundant historical precedent 
for that.



> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Remote participation to igovupdate BoF

[joel jaeggli]

The audio recordings for every session recorded  ietf87 are at:

http://www.ietf.org/audio/ietf87/

meetecho, which does a subset, is here

http://ietf87.conf.meetecho.com/



On Sep 26, 2013, at 11:52 PM, Alexandru Petrescu  
wrote:

> Side question -
> 
> I am wondering where are the video/audiologs of recent BoFs?  So I can 
> prepare what to to expect during a typical BoF.
> 
> Alex
> 
> Le 25/09/2013 00:29, Arturo Servin a écrit :
>> 
>> Thanks,
>> 
>> Jabber, and audio room is enough for me. Anything else is a plus.
>> 
>> Cheers,
>> as
>> 
>> On 9/24/13 6:25 PM, Yoav Nir wrote:
>>> Hi Arturo.
>>> 
>>> This BoF, like any other BoF or WG meeting, will have an audio stream and a 
>>> jabber room, and comments from the Jabber room will be channeled to the 
>>> room microphones.
>>> 
>>> The BoF chairs (yet to be determined) or the AD MAY request that the 
>>> meeting be covered with MeetEcho or WebEx. That's up to them, so you might 
>>> want to contact Jari about this.
>>> 
>>> Yoav
>>> 
>>> On Sep 25, 2013, at 12:12 AM, Arturo Servin 
>>>  wrote:
>>> 
 Hi,
 
I would like to request (if possible of course) remote participation
 for this BoF:
 
 igovupdate
 
I am not sure what are the proper channels for the request but I think
 it would be very valuable for remote participants to attend this meeting
 (including me that won't go to Vanc.).
 
 Thanks
 as
 
>> 
>> 
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]

[joel jaeggli]

On 9/22/13 11:35 AM, Scott Brim wrote:
> I like what Christian said. Also, perhaps we should figure out how to
> unbundle services and monetize what we can.
> 
> On Sep 22, 2013 1:38 PM, "Christian Huitema"  > wrote:
> 
> >> Yes. $$$. Nobody makes much/any money off email because it is
> >> so de-centralized. People who build wonderful new applications
> >> build them in a centralized way so that they can control them.
> >> And they want to control them so that they can monetize them.
> >
> > That is even true of the large email providers who are happy to
> > provide "free" email in return for being able leverage their
> > other products and/or "sell" the users and user base to
> > advertisers.
> 
> It is very true that innovation can only be sustained with a revenue
> stream. But we could argue that several services have now become
> pretty much standardized, with very little additional innovation
> going on.

There are it most be said enormous economies of scale that are hard to
ignore.

> Those services are prime candidates for an open and
> distributed implementation. I mean, could a WG design a service that
> provides a stream of personal updates and a store of pictures and is
> only accessible to my friends? And could providers make some
> business by selling personal servers, or maybe personal virtual
> servers? Maybe I am a dreamer, but hey, nothing ever happens if you
> don't dream of it!
> 
> -- Christian Huitema
> 
> 

Re: ORCID - unique identifiers for contributors

[joel jaeggli]

On 9/16/13 7:39 AM, Andy Mabbett wrote:
> [First post here]
> 
> Hello,
> 
> I'm a contributor to RFC 6350 - but I'm listed there by name only, and
> there is nothing to differentiate me from some other Andy Mabbett (the
> problem is no doubt worse for people with less unusual family names).
> Like many such contributors, I don't want to publish my email address
> as an identifier, in case I get spammed, and if I give an affiliation
> or even the URL of my website, that may change over time.

If the goal is to include contact info for the authors in the document
and in fact you can't be contacted using the info is it contact info?

> This problem is addressed by "Open Research Contributor Identifiers"
> (ORCID; ),  UIDs (and URIs) for scientific and other
> academic authors. Mine is below.
> 
> As the website says: "ORCID is an open, non-profit, community-driven
> effort to create and maintain a registry of unique researcher
> identifiers and a transparent method of linking research activities
> and outputs to these identifiers".
> 
> Individuals can sign up for an ORCID at  and then
> include it in their attribution in RfCs, in their research papers, and
> in other publications.
> 
> I'd like to propose that we strongly encourage, or even mandate, this
> for future RfCs.
> 
> How should I proceed? Is this list the best place for discussion of
> this topic? Does it need an RfC? If so, would someone care to assist
> me, please?
> 

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/11/13 9:39 PM, Lorenzo Colitti wrote:
> On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli  <mailto:joe...@bogus.com>> wrote:
> 
> The queue for dicussion of this point is closed. If there needs to be an
> appeal on this point now or in the future, then I'll be happy to help
> someone write it, but I consider that dicussion settled for the purposes
> of a draft that has already been tested for wg acceptance/wglc/ietf-lc
> 
> 
> To clarify - you're talking only about the discussion on whether this
> draft is in scope? Or are you saying that you consider all discussion of
> this document in this IETF last call settled?

The discussion of whether the IETF, or this working group is a suitable
location.

It was my opinion that the working group should revist the document
itself given what I saw in the last call.

joel

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/11/13 2:40 AM, Abdussalam Baryun wrote:
> On 9/9/13, Owen DeLong  wrote:
>> I have to agree with Lorenzo here again.
>>
>> This document seems to me to be:
>>
>>  1.  Out of scope for the IETF.
> 
> Please define what is the IETF scope? IMHO, IETF is scoped to do with
> IPv6 devices requirements and implementations. Do you think there is a
> RFC that considers thoes requirements?

The queue for dicussion of this point is closed. If there needs to be an
appeal on this point now or in the future, then I'll be happy to help
someone write it, but I consider that dicussion settled for the purposes
of a draft that has already been tested for wg acceptance/wglc/ietf-lc

> 
>>  2.  So watered down in its language as to use many words to say 
>> nearly
>> nothing.
> 
> No, the draft says things, I think if you read nothing that you did
> not read then. If you read, then what is your definition of saying
> nothing?
> 
>>  3.  Claims to be informational, but with so many caveats about the 
>> nature of
>> that
>>  information that it's hard to imagine what meaningful 
>> information an
>> independent
>>  reader could glean from the document.
> 
> I think this was mentioned clearly in the draft, which readers can understand.
> 
>>
>> Finally, given the spirited debate that has extended into this last call
>> (which I honestly wonder
>> how this ever saw last call over the sustained objections) definitely does
>> not appear to have
>> even rough consensus, nor does it appear to have running code.
> 
> IMHO, the LC is not for consensus, but it is for us to send the IESG
> our comments, and then they decide what is the IETF decision.
>>
>> Why is there such a push to do this?
> 
> Why is there a push to water-down it? I still was not convinced by
> your argument. However, Lorenzo comments should be considered by the
> draft as the authors are working on.
> 
> AB
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/9/13 1:06 PM, Owen DeLong wrote:
> I have to agree with Lorenzo here again.
> 
> This document seems to me to be:
> 
> 1.Out of scope for the IETF.

AD here... let's put this one to bed. there are existance proof(s) of
previous work in this area and others that covers similar ground.

I don't believe that this is out of scope for the WG or the IETF,
Neither did the previous AD.

So... Focus on the contents.

> 2.So watered down in its language as to use many words to say nearly
> nothing.
> 3.Claims to be informational, but with so many caveats about the nature
> of that
> information that it's hard to imagine what meaningful information an
> independent
> reader could glean from the document.
> 
> Finally, given the spirited debate that has extended into this last call
> (which I honestly wonder
> how this ever saw last call over the sustained objections) definitely
> does not appear to have
> even rough consensus, nor does it appear to have running code.
> 
> Why is there such a push to do this?
> 
> Owen
> 
> On Sep 9, 2013, at 05:16 ,  > wrote:
> 
>> Re-,
>>  
>> Please see inline.
>>  
>> Cheers,
>> Med
>>  
>> *De :* Lorenzo Colitti [mailto:lore...@google.com ] 
>> *Envoyé :* lundi 9 septembre 2013 13:24
>> *À :* BOUCADAIR Mohamed IMT/OLN
>> *Cc :* Dave Cridland; v6...@ietf.org  WG; BINET
>> David IMT/OLN; IETF Discussion
>> *Objet :* Re: [v6ops] Last Call:
>>  (Internet Protocol
>> Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
>>  
>> On Mon, Sep 9, 2013 at 8:06 PM, > > wrote:
>>
>> The document explicitly says “This document is not a standard.”
>> since version -00.
>>
>>  
>>
>> What additional statement you would like to see added?
>>
>>  
>> I think the high-order points are:
>>  
>> 1. The text "This document defines an IPv6 profile for 3GPP mobile
>> devices. It lists the set of features a 3GPP mobile device is to be
>> compliant with to connect to an IPv6-only or dual-stack wireless
>> network" should be replaced with "This document defines an IPv6
>> profile for 3GPP mobile devices that a number of operators believe is
>> necessary to deploy IPv6 on an IPv6-only or dual-stack wireless
>> network (including 3GPP cellular network and IEEE 802.11 network)."
>>  
>> In place of "a number of operators believe is necessary to deploy" you
>> could have "intend to deploy" or "require". I'd guess that as long as
>> it's clear that the requirements don't come from the IETF but from a
>> number of operators (not all of them, or a majority of them), it
>> doesn't matter exactly what you say.
>> */[Med] I made this change:/*
>> */ /*
>> */OLD:/*
>> */ /*
>>This document defines an IPv6 profile for 3GPP mobile devices.  It
>>lists the set of features a 3GPP mobile device is to be compliant
>>with to connect to an IPv6-only or dual-stack wireless network
>>(including 3GPP cellular network and IEEE 802.11 network).
>> */ /*
>> */New:/*
>> */ /*
>>This document defines an IPv6 profile that a number of operators
>>require in order to connect 3GPP mobile devices to an IPv6-only or
>>dual-stack wireless network (including 3GPP cellular network and IEEE
>>802.11 network).
>> */
>>
>> /*
>> 2. In the normative language section, I'd like to see a statement
>> similar to what's in RFC 6092. Perhaps something like this?
>> */[Med] I used the same wording as in RFC6092. The change is as follows:/*
>> */ /*
>> */OLD:/*
>> */ /*
>>This document is not a standard.  It uses the normative keywords only
>>for precision.
>> */ /*
>> */NEW:/*
>> */ /*
>>   NOTE WELL: This document is not a standard, and conformance with
>>   it is not required in order to claim conformance with IETF
>>   standards for IPv6.  It uses the normative keywords defined in the
>>   previous section only for precision.
>> */ /*
>> ___
>> v6ops mailing list
>> v6...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/v6ops
> 

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/9/13 4:24 AM, Lorenzo Colitti wrote:
> On Mon, Sep 9, 2013 at 8:06 PM,  > wrote:
> 
> The document explicitly says “This document is not a standard.”
> since version -00.
> 
> __ __
> 
> What additional statement you would like to see added?
> 
> 
> I think the high-order points are:
> 
> 1. The text "This document defines an IPv6 profile for 3GPP mobile
> devices. It lists the set of features a 3GPP mobile device is to be
> compliant with to connect to an IPv6-only or dual-stack wireless
> network" should be replaced with "This document defines an IPv6 profile
> for 3GPP mobile devices that a number of operators believe is necessary
> to deploy IPv6 on an IPv6-only or dual-stack wireless network (including
> 3GPP cellular network and IEEE 802.11 network)."
> 
> In place of "a number of operators believe is necessary to deploy" you
> could have "intend to deploy" or "require". I'd guess that as long as
> it's clear that the requirements don't come from the IETF but from a
> number of operators (not all of them, or a majority of them), it doesn't
> matter exactly what you say.

So this is a problem, and part of the reason I had enough concern about
this document to not take it forward. being genereous the consensus on
this document is pretty rough. if the outcome doesn't include the
consent of implementors it's not very good advice.

> 2. In the normative language section, I'd like to see a statement
> similar to what's in RFC 6092. Perhaps something like this?
> 
> 1.3.  Use of Normative Keywords
> 
>   NOTE WELL: This document is not a standard. Conformance with it is
>   not required to deploy IPv6 in mobile networks or to claim conformance
>   with IETFstandards for IPv6.  It uses the normative keywords
> defined in the
>   previous section only for precision.
> 
> Regards,
> Lorenzo

Re: Equably when it comes to privacy

[joel jaeggli]

On 9/8/13 4:36 PM, SM wrote:
> Hi Joel,
> At 11:59 08-09-2013, joel jaeggli wrote:
>> Should your tools, the contents of your mind, and the various effects
>> and context of your personal communication become instruments of
>> state-power? Because the tools we've built are certainly capable of that.
> 
> Yes.  That's not a good motivation to give up on privacy though.

It is not. That said, the chickens are coming home to roost.


> Regards,
> -sm
> 
> 
> 

Re: Equably when it comes to privacy

[joel jaeggli]

On 9/8/13 10:37 AM, SM wrote:
> At 07:07 08-09-2013, Jorge Amodio wrote:
>> You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia 
> 
> There were people from Pakistan who participated in the IETF.  I recall
> an email exchange where a person from that country received an
> unpleasant comment from someone who is part of the IETF "leadership".
> 
> In my opinion a discussion about Country X or Country Y would take the
> thread downhill.  It can also have a chilling effect.

State employment of legal and extra-legal means to spy on and capitalize
the activities of their own citizens and those of other states is
something that transcends boundries, cultural identity or ideology. It
doesn't much matter if you're David Dellinger, Neda Agha Sultan, Khalid
El-Masri, etc, if you'd ended up on the wrong side of a state apparatus,
well you're going to have a bad time of it.

Should your tools, the contents of your mind, and the various effects
and context of your personal communication become instruments of
state-power? Because the tools we've built are certainly capable of that.

> At 05:14 08-09-2013, Phillip Hallam-Baker wrote:
>> Another worrying aspect of [censored] is that it is named
>> after[censored]. They seem to be looking to make [censored] out of us.
>> They certainly seem to be endorsing [censored]. What should we think
>> if the [censored] had a similar program codenamed [censored]?
> 
> It would not look good.
> 
> Regards,
> -sm

Re: Berlin was awesome, let's come again

[joel jaeggli]

On 8/2/13 12:58 PM, Eggert, Lars wrote:
> Venue was great, food options here and in the city were great, all-around 
> great experience. Let's come again!
>
> (I do kinda wonder how there wasn't a single local company willing to step up 
> to be the host. That's embarrassing to me as a German, esp. if the IETF meets 
> in the self-declared IT hub of Germany. Better luck next time, I hope.)
There were many great sponsors stepped up they should be appreciated for
their generosity. Sometimes it's hard to hard to find a host, that's not
a reflection those who have invested time/energy/capital in making the
meeting a success.
> Lars

Re: Bringing back Internet transparency

[joel jaeggli]

On 8/2/13 8:50 AM, Marc Petit-Huguenin wrote:
> On 08/02/2013 08:28 AM, Keith Moore wrote:
>
> > On Aug 1, 2013, at 9:14 PM, Noel Chiappa wrote:
>
> >>> From: Phillip Hallam-Baker 
> >>
> >>> The ISPs had a clear interest in killing of NAT which threatened the
> >>> ISP business model.
> >>
> >> So this is rather amusing: you're trying to tell me that ISPs wanted to
> >> kill NAT, and I have other people telling me NAT was an intergral
> part of
> >> ISPs' master plan to take over the universe.
> >>
> >> Clearly you all both can't be right.
>
> > ISPs were against NATs at first.   It was only later that they embraced
> > them.
>
>
> This mess is still the ISP fault.  If they gave users what they
> wanted, which
> is multiple IP addresses, then they wouldn't have to install NAT (I am
> still
> paying $9.95 per month for the privilege of having 4 additional IPv4
> addresses
> on my Comcast connection).  And that would have accelerated IPv6
> deployment.
>
Wierdly, I don't actually want to bridge my home network to my ISP nor
are they frankly likely to accommodate my need for a /27 without some
consideration, while there are plenty of ways that can be achieved with
IPv4 they have more friction and therefore cost for the isp and the
consumer then simply receiving one ip via dhcp and getting on with my 
life. it's also somewhat convenient when that primary provider is down
that the network can be hung off an LTE connection (renumbering isn't a
problem, dhcp can address that, getting one IP is).

My current CPE does DHCPv6 PD and comcast accommodates me accordingly. I
hope verizon LTE will eventually.
> The firewall issue is orthogonal (which I put the blame on Microsoft
> sloppy
> coding practices).
>
Windows machines are not principally the devices on my homenet whose
code I don't trust. consumer electronics don't get a lot of software
updates.

>

Re: 6tsch BoF

[joel jaeggli]

On 8/1/13 6:25 PM, Melinda Shore wrote:
> On 8/1/13 1:29 AM, joel jaeggli wrote:
>> Consensus for any particular outcome is in the end a judgment call.
> Well, yes and no, but this situation strikes me as odd, and probably
> a mistake on the part of the chairs.  If you can't tell whether or
> not you've got consensus, you don't have consensus.
Yes agree The distinction of none or any variant of something else is a
judgement call.
>   It sounds like
> they were treating the hum as a vote in the first place (which we
> do entirely too often).
I see nothing wrong with taking the temperature of the room.  further
exposition on the mailing list might be a discriminator that would be
easier to identify the positions and what action should therefore occur.
>
> Melinda
>

Re: 6tsch BoF

[joel jaeggli]

On 8/1/13 11:14 AM, Andy Bierman wrote:
> Hi,
>
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.
> The sum of the amplitude of all hums is not.
Consensus for any particular outcome is in the end a judgment call.
> Andy
>
> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>> the work discussed in the BoF to be thought-provoking.
>>
>> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
>> that the IETF should address?"  First, the chairs asked for a hum.  From my 
>> vantage point (middle of the room), the hum was pretty close to equal, 
>> for/against.  I reviewed the audio 
>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
>> decided they needed more information than they could extract from the hum, 
>> so they asked for a show of hands.  From the audio record, there were "a 
>> lot" for (which matches my recollection) and "a handful" against (my memory 
>> is that no hands showed against).  There was a request to ask for a show of 
>> hands for "how many don't know".  The question was asked, and the record 
>> shows "a dozen".
>>
>> So, there was apparently a complete change in the answer to the question 
>> based on humming versus voting.  There may also have been some effect from 
>> asking, after the fact, for a show of hands for "don't know".
>>
>> I'm really curious about the results, which indicate that, at least in this 
>> case, the response to the question is heavily dependent on the on the mode 
>> used to obtain the answers to the question (which we all know is possible).  
>> In particular, the effect of humming versus show of hands was pretty 
>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>> preferred over a show of hands.  From this example, it seems to me to be 
>> worth considering whether a more honest and accurate result is obtained 
>> through humming rather than a show of hands.
>>
>> The other question raised in my mind is why the initial result from the hum, 
>> which did not have a consensus either way, was not sufficient.  "Roughly the 
>> same response" for/against the question would seem to me to be as valid a 
>> result as explicit consensus one way or the other, and the act of taking a 
>> show of hands to survey the appeared to treat the hum as irrelevant, rather 
>> than highly significant.
>>
>> - Ralph
>>

Re: IETF-Blog comments (Was Re: setting a goal for an inclusive IETF)

[joel jaeggli]

On 7/30/13 4:40 PM, Arturo Servin wrote:
> Captchas? Recaptchas?
>
> Also, AFAIK WordPress has some good anti-spam add-ons.
the obvious one is simply a requirement to use your ietf tools
credientials to post.
>
> Regards,
> as
>
>
>
>
> On 7/30/13 4:34 PM, Jari Arkko wrote:
>> Arturo:
>>
>>> Now, something general related to the blog. Perhaps it would be good to
>>> enable comments, isn't it?
>> Yes, that has been issue that has bugged me as well. The IT team tells me 
>> that it is problematic from a spam perspective, and they do not want me 
>> spending my time approving/removing comments. I don't have practical 
>> experience if that's a real issue on this platform (WordPress), though in 
>> other similar arrangements it has not been a big problem in my experience. 
>> Maybe the IETF community has some advice to us on this...
>>
>> Jari
>>

Re: Remote participants, newcomers, and tutorials

[joel jaeggli]

On 7/29/13 7:25 AM, Dave Crocker wrote:
>
>  My suggestion is for a 'status' page that gives a brief summary
> about the current state of the working group, ideally listing the
> current, near-term vector of the work -- what's the current focus of
> effort -- and major open issues.
>
>  I'll suggest that it be updated after every meeting.
>
> Arguably, this sort of status statement is good to have even without
> newcomers, since it forces working groups to face the question of what
> progress they are and are not making.
>
> An exercise like this can be cast as onerous or helpful, depending
> upon the surrounding organizational 'tone' we use.  In a supportive
> environment, the exercise is helpful.  In a hostile one, not so much.
>
> Basically, if a wg is being diligent and candid in summarizing its
> problems (as well as progress) the rest of us have an obligation to be
> helpful.
http://trac.tools.ietf.org/area/ops/trac/wiki/IETF86summary

is the ops area's experiment with doing this.
>
>
> d/
>

Re: Remote participation and meeting mailing lists

[joel jaeggli]

On 7/24/13 9:07 AM, John C Klensin wrote:


--On Wednesday, July 24, 2013 06:43 -0800 Melinda Shore
 wrote:


On 7/24/13 12:30 AM, John C Klensin wrote:

Yes.  I was thinking a bit more generally.  For example,
schedule changes during the meeting week, IIR, go to NNall,
and not ietf-announce.   As a remote participant, one might
prefer to avoid the usual (and interminable) discussions

...
Yes, the meeting mailing lists are here:
http://www.ietf.org/meeting/email-list.html

Yes, but...

(1) A hypothetical remote participating newcomer is expected to
find that how?  I note that the IETF home page links to mailing
lists do not list either 87all or 87attendees in any of the
obvious places.

(2) That page provides a mechanism for subscribing to
87attendees (the cookies and coffee and, I assume,
bumped-from-hotel-attendees very soon, discussion list) but not
a link to the far more important for remote folks 87all.   If
there is a way to subscribe to that without registering, I
haven't found it.

Note to remote participants:   The cookies and coffee list is
also where a lot of comments about the meeting network and
related facilities appears.  While most remote participants
don't need to know how poorly the network works in some
alternate hotel, information about Meetecho and Webex status
tends to appear there too.
We try to keep that in the IETF list since it's of presumed utility to 
the entire ietf  community.

 john

Re: All fees include 19% VAT?

[joel jaeggli]

On 7/11/13 5:55 PM, Will Liu (Shucheng) wrote:


Folks,

I am a little confused by the following words. The sum for an early 
bird is 650$, right? Or do we need to pay extra VAT (which make the 
sum larger than 650$)? The last sentence is really confusing.


The vat is included. $650 is what you're paying and what the bill will 
be for.


Early-Bird: $650 USD,*if paid in full*prior to 2400 UTC July 19, 2013.

All fees include 19% VAT

A FINAL receipt will be sent with all the required VAT information by 
July 28th. Instructions will be included on the process to follow to 
recover the VAT paid by qualified attendees or their employer.


Regards,

Shucheng (Will)

---

Shucheng LIU (Will), Ph.D.

Research Engineer  at  Huawei Technologies Co.,Ltd

Email: liushuch...@huawei.com 

http://cn.linkedin.com/in/shucheng

---

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 6/20/13 10:04 AM, Doug Barton wrote:


I agree with at least a little of what each of Olafur, John, and 
Andrew have said; but I think there's a middle ground between "throw 
the doors wide open" and "everything we have tried before didn't 
work." At least I hope there is.


Well recall that we still have DNSOP, which along with the dnsext 
mailing list once the wg is closed is probably a reasonable place to 
get/look for feedback.
Perhaps we could have a non-WG mailing list so that people could 
submit proposals for review prior to the expert review process. Even 
some of the "get off my lawn" crowd offered good suggestions for this 
EUI case (make 1 record with a size field rather than 2 records) that 
could have made this whole process a lot smoother.
My impression of the outcome of the procedure change for the registry is 
the wg didn't feel that there should be any particular obstacle  beyond 
expert review for registration. It is possible that reasonable people 
should disagree on the application of given rr-types and that they 
should be registered anyway.


In 30 years we've allocated ~120 rrtypes most of which we don't use   
anymore.


Doug

Re: Lessons from PROVREG WG was Re: IETF, ICANN and Whois...

[joel jaeggli]

On 6/19/13 9:01 AM, Edward Lewis wrote:


Looking back in hindsight, what would help is to have some means for 
the IETF to provide a maintenance vehicle for it's products.  Or 
realize that the "waterfall model" that seems to be in place is no 
longer appropriate.  (As if you've never heard that before!)  The 
world changes (the new majority) but the IETF acts as if "once it's an 
RFC it is done."


Are we perhaps not using area meetings with the effectiveness that we 
should be? Now that I'm cutting my teeth on the AD sponsoring thing I'm 
begining to understand why AD's are reluctant to use the tool liberally 
and the next best place assuming the existance of a critical mass of 
existing participants would be for example appsawg.
This is an example of an ICANN initiated piece of work that barely got 
into the IETF, the IETF completed it in a way that has benefit beyond 
ICANN (meaning many ccTLDs have adopted it on their own accord), but 
the IETF didn't make it easy and didn't help the deployment.  I hope 
the latter phase isn't repeated with the WEIRDS WG and RDAP.


PS. With WEIRDS there's a much more substantial industry and majority 
than "back in the day".  Just something to keep in mind.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar   You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

Given that this document was revved twice and had it's requested status 
change during IETF last call in response to discussion criticism and new 
contribution I am going to rerun the last call.


Thanks
joel

On 5/20/13 6:44 AM, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
as 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 2013-06-17. 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


48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
Unique Identifiers (EUI-64) are address formats specified by the IEEE
for use in various layer-2 networks, e.g. ethernet.

This document defines two new DNS resource record types, EUI48 and
EUI64, for encoding ethernet addresses in the DNS.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/


No IPR declarations have been submitted directly on this I-D.

Re: Last Call: (Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information) to Internet Standard

[joel jaeggli]

The last call is being rerun to capture an import change to the 
rfc5101bis namely the requested status for "Specification of the IP Flow 
Information eXport (IPFIX) Protocol for the Exchange of Flow 
Information" Internet Standard rather than proposed.


Thank you
Joel

On 6/14/13 3:24 PM, The IESG wrote:

The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Specification of the IP Flow Information eXport (IPFIX) Protocol for
the Exchange of Flow Information'
as Internet 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 2013-06-28. 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 specifies the IP Flow Information Export (IPFIX)
protocol that serves for transmitting Traffic Flow information over
the network. In order to transmit Traffic Flow information from an
Exporting Process to a Collecting Process, a common representation of
flow data and a standard means of communicating them is required.
This document describes how the IPFIX Data and Template Records are
carried over a number of transport protocols from an IPFIX Exporting
Process to an IPFIX Collecting Process. This document obsoletes RFC
5101.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ballot/


The following IPR Declarations may be related to this I-D:

http://datatracker.ietf.org/ipr/1927/

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

I am told that draft has been revved again in response to discussion on 
the list.


http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05

Please direct your attention to the security considerations section. If 
it turns out that informational documentation of the two RR-Type 
assignments remains controversial, I will likely withdraw my sponsorship 
of this draft.


Thanks
joel


On 5/27/13 5:40 PM, joel jaeggli wrote:

On 5/20/13 6:44 AM, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
as Proposed Standard


I would direct the attention of the commentors to draft 04

http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt 



Which addresses concerns expressed in IETF last call over the intended 
status.


It also incorporates edits proposed by John Klensin in his review.

Notes: from the author:

 - changed intended status to informational

 - incorporation of John's suggestions in the Terminology section, to 
indicate that we're using 2119 keywords even though this is not a 
standards track document


 - added a couple of sentences to the security considerations sections 
to underscore the fact that this document specifies optional 
mechanisms that people might well not use if privacy considerations 
dictate otherwise




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 2013-06-17. 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


48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
Unique Identifiers (EUI-64) are address formats specified by the 
IEEE

for use in various layer-2 networks, e.g. ethernet.

This document defines two new DNS resource record types, EUI48 and
EUI64, for encoding ethernet addresses in the DNS.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ 




No IPR declarations have been submitted directly on this I-D.

Re: Content-free Last Call comments

[joel jaeggli]

On 6/12/13 9:42 PM, Ted Lemon wrote:

On Jun 12, 2013, at 3:31 PM, Peter Saint-Andre  wrote:

I think these messages are useless, not harmful. But perhaps I have
more confidence in the inherent skepticism of your average IETF
participant than Pete does...

FWIW, until I read Pete's document on consensus, I thought that +1 statements 
were part of the consensus process.   This was not a strongly held opinion—it 
was just my understanding of how consensus operated, from having watched other 
working group chairs run their working groups.   I think the point Pete is 
making is very important, because the consensus process Pete describes is more 
in keeping with how I think the IETF ought to operate than the process in which 
+1 counts for something.

+1 / -1

are conventions that crept in from other standards bodies, they don't 
have any particular place or meaning here, apart from what you can 
literally interpret them as e.g. the equivalent of hand raising in 
agreement or disagreement.


(BTW, in case it wasn't obvious, I've been engaging in this discussion with my 
AD and working group chair experience in the back of my mind, but my AD hat 
off.)

Re: Weekly posting summary for ietf@ietf.org

[joel jaeggli]

On 6/7/13 6:03 PM, Tim Chown wrote:
On 7 Jun 2013, at 16:52, Ted Lemon > wrote:


On Jun 7, 2013, at 11:48 AM, Andy Bierman > wrote:

So why not move the signal?
Put IETF Last Call mail onlast-c...@ietf.org 
and leave this list for everything else.


The discussion still has to happen somewhere.   I certainly am not 
restricting my meaningful participation in last calls, but even in 
that case it is important to be restrained and not get into long 
fruitless discussions, which, I am afraid, I am wont to do.


It's a significant problem for those who *have* to read the threads, 
in particular document authors, WG chairs, and ADs. Hats off to them 
for keeping up with it where they need to.


As another example, the v6ops list has recently also had four threads 
run well over the 100 message count, specifically end to end response 
time, ULA usage, "being careful" about ULAs and the semantic prefix 
thread.
v6ops had a single draft which attracted ~1100 messages over the course 
of a year so this isn't new or unusual over there. A small number of 
posters tend to be the majority of the volume on several topics, so if 
you're reading to understand the positions of the working group or to 
measure consensus on the list some judicious sorting is required.
Of course, a healthy debate is a good thing, as is having an open 
process for discussion. If we had very few comments that would 
certainly not be good either. But I fear that some valuable 
contributions are either being drowned out, or that some people with 
valuable input are being put off contributing.



Tim

Re: Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC

[joel jaeggli]

On 6/6/13 3:15 AM, Abdussalam Baryun wrote:

I send my request to the editors including questions but no reply from
them to me. The thread [1] raised some issues, which is not mentioned
in the I-D. The message [2] was ignored not answered (this is last
reminder). The message [3] proposes using RFC5444 into this I-D, or
raise the question of why not using MANET packet format within MANET
domains (I need an answer).

[1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html
[2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html
[3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html

The I-D SHOULD not go forward if it still ignores the IETF community questions.
This sounds like an appeal of the working group consensus, not a last 
call comment.


If you have concerns with the WGLC those are raised first with the 
chairs, then with responsible AD, and then with the IESG as a whole.


I would observe that consensus does not require universal agreement. If 
you're in the rough from the vantage point of others, it's worth 
considering whether political capital, goodwill and the forebearance of 
your peers are best expended on this point.


Regards
AB

On 6/5/13, The IESG  wrote:

The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
as Experimental 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 2013-06-19. 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


RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
(MANETs) by specifying its operation on the new OSPF interface of type
MANET.  This document describes the use of OSPF-MDR in a single-hop
broadcast network, which is a special case of a MANET in which each
router is a (one-hop) neighbor of each other router.  Unlike an OSPF
broadcast interface, such an interface can have a different cost
associated with each neighbor.  The document includes configuration
recommendations and simplified mechanisms that can be used in single-hop
broadcast networks.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/


No IPR declarations have been submitted directly on this I-D.

Re: Time in the Air

[joel jaeggli]

On 5/31/13 12:18 PM, Scott Brim wrote:

On Friday, May 31, 2013, Dave Crocker wrote:

On 5/31/2013 8:12 PM, Scott Brim wrote:

We'll have multiple airships, one for each set of related
meeting rooms.



is dirigible a new term of endearment for an AD?


Obviously the ADs have a small helicopter so they can get between 
dirigibles.

It's more like Icarus...

Re: IETF Meeting in South America

[joel jaeggli]

On 5/28/13 11:56 AM, Christian O'Flaherty wrote:

It would seem likely when the participation is heaviliy biased towards
equipment vendors and software tooling that the participants would be more
representative of where the concentration of the development sideo of that
work occurs.

This is true, but this is also something where active participants can
help. Many of those companies also have R&D groups in Latam but
unfortunately they're not yet active in the IETF. This is probably for
historical reasons but it's feasible to change. If you know in your
companies, groups or individuals valuable enough to work in the IETF
please reach them and help them (or let me know and I'll do it).
$former_dayjob had a R&D office in manaus. We have active kernel/gtk/qt 
development going on there with real contributors. It is however an 
isolated kind of strange tax haven in the middle of the amazon  and it's 
kind of hard to get to.

Comparative advantage isn't just the domain of agricultural
products, extractive industries, and low-cost manufacturing. That seems
likely to be part and parcel of the diversity discussion.

Latam is not just agriculture and cows :-)
I am within about 10 minutes driving distance of maybe 1/3 the world's 
ethernet switch asic design capacity, so to ignore the fact that 
concetration and specialization does occur is a little short sighted, it 
also changes over time when the basis for advantage no longer applies, 
or erodes).

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/28/13 9:41 AM, SM wrote:

Hi Joe,
At 03:12 28-05-2013, Joe Abley wrote:

Note that there's no suggestion that these RRTypes are required by the
CRTC. The example given was for a situation where Interop would have
been beneficial (so that cable resellers have an obvious, stable and
supported way of encoding this kind of information.


Ok.


The opposite actually: cable operators are required to provide access
to subscribers on behalf of third parties in order to promote
competition. There are multiple such cable providers and multiple such
resellers.


Yes.

(TekSavvy is one such reseller of multiple cable companies' access 
networks.)


Ok.


Feel free to point out the gaps, and/or to suggest text.


I'll give it a try.  I suggest talking to the Area Director to see 
what's workable.


I would drop Section 6 of the draft as I no longer need a use case to 
get an RRTYPE assignment.  There is a typo for "RRTPES" in Section 7.  
I would start Section 9 with "There are privacy concerns ...".  I 
would replace the third paragraph with:


For some background. The usecase facilitates discussion and 
justification of the draft. It is not about justifying the RRtype (which 
was assigned under the rules of that registry).


It's in there because the sponsoring AD requested it after feedback 
during the dnsext dicussion.

  The user should be provided with a disclosure statement that clearly
  mentions:

  - How the EUI addresses published in DNS will be used and protected

  - What privacy policies are applicable

  The disclosure statement is to enable the user to make an informed 
decision
  about whether the disclosure of the information is acceptable 
considering

  local laws and customs.

I would rename Section 9 as "Privacy Considerations".  I don't know 
what to put in the new Security Considerations section. Maybe 
"Publishing EUI addresses in DNS lowers the security of the Internet".


Regards,
-sm

Re: IETF Meeting in South America

[joel jaeggli]

On 5/23/13 8:02 PM, David Conrad wrote:

On May 23, 2013, at 7:44 PM, Melinda Shore  wrote:

So the question is why we aren't seeing more drafts, reviews, and
discussions from people in Central and South America,

Language?
It would seem likely when the participation is heaviliy biased towards 
equipment vendors and software tooling that the participants would be 
more representative of where the concentration of the development sideo 
of that work occurs. Comparative advantage isn't just the domain of 
agricultural products, extractive industries, and low-cost 
manufacturing. That seems likely to be part and parcel of the diversity 
discussion.

Re: Last Call: (Resource R ecords for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/28/13 8:18 AM, Randy Bush wrote:

What is at issue, IMO, is whether the Internet is better off
having a couple of RRTYPEs around with no documentation or
having them documented.

there are two solutions to this

Probably more than two if your comment indicates that you agree
that having registered RRTYPEs documented is, on balance, better
than not having them documented:

(1) We can continue along the path of Informational RFC
publication in the IETF Stream

(2) Joe could have submitted the document to the ISE and
requested Informational RFC publication in the Independent
stream.

(3) Joe could post the definitional document on a web site
somewhere that could provide a stable reference and then ask
IANA to incorporate that reference, presumably in URL form,
rather than the name of an I-D in the registry.  If this is a
Canadian initiative, perhaps the Canadian government would like
to provide that location and reference but, clearly, there are
other alternatives.

Did you have something else in mind?

remove the rrtypes from the registry

Unless you're proposing that we change the operation of the registry 
that seems a bit out of scope.

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/20/13 6:44 AM, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
as Proposed Standard


I would direct the attention of the commentors to draft 04

http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt

Which addresses concerns expressed in IETF last call over the intended 
status.


It also incorporates edits proposed by John Klensin in his review.

Notes: from the author:

 - changed intended status to informational

 - incorporation of John's suggestions in the Terminology section, to indicate 
that we're using 2119 keywords even though this is not a standards track 
document

 - added a couple of sentences to the security considerations sections to 
underscore the fact that this document specifies optional mechanisms that 
people might well not use if privacy considerations dictate otherwise



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 2013-06-17. 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


48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
Unique Identifiers (EUI-64) are address formats specified by the IEEE
for use in various layer-2 networks, e.g. ethernet.

This document defines two new DNS resource record types, EUI48 and
EUI64, for encoding ethernet addresses in the DNS.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/


No IPR declarations have been submitted directly on this I-D.

Re: More participation from under-represented regions

[joel jaeggli]

On 5/26/13 4:01 PM, SM wrote:

Hi Edwin,
At 13:59 26-05-2013, Edwin A. Opare wrote:
The awareness creation should start at the grassroots level : "The 
Universities"!. Train the soon-to-graduate Computer 
Scientist/Engineer on the values and essence of the IETF and it'll 
forever be with them even after graduation.


To elicit participation from the under-represented regions, the 
universities are a sure starting point, then a lot more 
industry-focused awareness creation by the ISOC local Chapters.


AfNOG has trained hundreds of people in Africa.  Those people do not 
participate on the mailing list.
They are network operators, system adminstrators, students and NGO 
participants bootstraping parts of the experience by participating in 
activities with their regional peers. A week-long series of workshops 
held once a year has some worthwhile goals and notable sucesses I don't 
think of it a fertile training ground for new IETF participants.
There are some people from Africa who have attended IETF meetings.  
They don't participate in the IETF.  Why is it that there are some 
participants from South America whereas there aren't any participants 
from Africa?
People come to the IETF with work because they have a problem which the 
work product of their contribution through the IETF activity addresses.  
That's fairly expensive, time consuming, and has uncertain results.


There are past and present contributors from various parts of the 
continent, I've had the privilege of working with some of them.


Regards,
-sm

Re: IETF Meeting in South America

[joel jaeggli]

On 5/24/13 11:37 AM, Doug Barton wrote:

On 05/24/2013 11:29 AM, joel jaeggli wrote:

probably because I've been involved in the planning loop since 44.


... and you're also involved in planning for LACNIC, LACTLD, LACNOG, 
and every other regional organization in Latin America that might be 
interested in running their meeting before or after ours?


The question was whether the IETF dates are fungible. They aren't. I 
would like them to be rather more fungible and I'm apparently in the 
minority. There is a reason why the colocated ieee meeting with the IETF 
occured something like 6 years after it was proposed.

Re: IETF Meeting in South America

[joel jaeggli]

On 5/24/13 11:24 AM, Doug Barton wrote:

On 05/24/2013 11:21 AM, joel jaeggli wrote:

The consistent feedback regarding non-conflict as long as I been
involved in this tends to indicate otherwise. 18-months to 2 years seems
much more reasonable to me personally.


Joel,

You're making several fundamental mistakes in your thinking. Rather 
than focusing on all the reasons you think it cannot happen, why not 
take the suggestion for what it was (it would be nice if we could do ...),

probably because I've been involved in the planning loop since 44.
and let the folks who actually do the scheduling decide if the idea is 
worth pursuing, and if so if it is possible.

Doug

Re: IETF Meeting in South America

[joel jaeggli]

On 5/24/13 11:05 AM, Richard Barnes wrote:
On Fri, May 24, 2013 at 2:03 PM, joel jaeggli <mailto:joe...@bogus.com>> wrote:


On 5/24/13 10:43 AM, Doug Barton wrote:

While it's unlikely that I would be able to attend, I think
it's an excellent idea for reasons already better stated by
others, and BA is a very nice city.

The only suggestion I might add that I haven't seen mentioned
yet (and pardon me if I missed it) would be to perhaps
schedule the meeting to piggy back on one of the excellent
regional meetings that is already well established. Arturo
gave a good list, IME LACNIC and LACTLD would be the best/most
obvious candidates. By running the IETF meeting either the
week before, or the week after one of those meetings we would
be able to get quite a bit of cross-pollination, especially
with the availability of day passes.

The dates for our meetings are already fixed out to november 2022.


Given that I don't think there are stone tablets involved, presumably 
they could still be moved if there were a good reason.
The consistent feedback regarding non-conflict as long as I been 
involved in this tends to indicate otherwise. 18-months to 2 years seems 
much more reasonable to me personally.


While there are various sorts of force majeure events that could no 
doubt alter the dates I don't see it as likely that they are otherwise 
flexible. ieee plenary sessions are scehduled out to july 2018 for example.


http://www.ietf.org/meeting/clash-list.html

is long

It's not like people have already booked plane tickets to BA.

hth,

Doug

Re: IETF Meeting in South America

[joel jaeggli]

On 5/24/13 10:43 AM, Doug Barton wrote:
While it's unlikely that I would be able to attend, I think it's an 
excellent idea for reasons already better stated by others, and BA is 
a very nice city.


The only suggestion I might add that I haven't seen mentioned yet (and 
pardon me if I missed it) would be to perhaps schedule the meeting to 
piggy back on one of the excellent regional meetings that is already 
well established. Arturo gave a good list, IME LACNIC and LACTLD would 
be the best/most obvious candidates. By running the IETF meeting 
either the week before, or the week after one of those meetings we 
would be able to get quite a bit of cross-pollination, especially with 
the availability of day passes.

The dates for our meetings are already fixed out to november 2022.

hth,

Doug

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/21/13 9:02 AM, Keith Moore wrote:

On 05/21/2013 11:57 AM, Joe Abley wrote:

On 2013-05-21, at 11:56, Keith Moore  wrote:

2119 language is intended to describe requirements of 
standards-track documents.Informational documents cannot impose 
requirements.
Then I think we've just identified a reason why this document should 
be on the standards track.


Actually I think that what we need is a BCP that says that DNS is not 
intended, not designed, and SHOULD NOT be used for dissemination of 
any information that is not deemed acceptable for widespread public 
distribution.
The basically rules out every internal split  horizon use of DNS in 
existence.


scope matters for this application just as it does for any zone you 
shouldn't be exposing to the outside world.
   Neither the DNS protocol nor DNS implementations are designed to 
meet the security requirements of such applications, and DNS is too 
widely deployed to change that.

Keith

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/21/13 8:06 AM, John C Klensin wrote:


   All I'm asking for is that, if you
want this as a Proposed Standard you carefully and convincingly
describe your design rationale.  I want that both because it
seems generally appropriate in this case and because, if someone
comes along and wants to register the EUI64-with-embedding or
EUI-with-48-64-switch RRTYPEs and there is pushback because
EUI48 and EUI64 are already registered,
It seems like we're still re-arguing the assignment of the rr-types. It 
doesn't seem like future assignments are likely to have anymore pushback 
than present.


With respect to the question of proposed standard. What changes if the 
requested status is informational?

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/20/13 6:42 PM, Brian E Carpenter wrote:

On 21/05/2013 13:06, John C Klensin wrote:

--On Monday, May 20, 2013 19:49 -0400 Rob Austein
 wrote:


At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote:

This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or other indicator in the DATA
field as to whether a 48 bit or 64 bit identifier was present?

Short answer: Probably not, but it depends on the application.

Longer answer: See RFC 5507.

Rob,

I've reread 5507 and did so again before writing my second note
today.  I don't see that it helps.

I haven't heard anyone proposing use of TXT (or any existing
RRTYPE) instead, so that is presumably a non-issue.

The discussion in 3.1 clearly applies to relatively complex
schemes like NAPTR, but it is not clear that it has anything to
do with this case.  In particular, if I correctly understand the
IEEE's allocation scheme for longer identifiers (and I may not)
than a given device gets only one -- this is not analogous to a
dual-stack IPv4/IPv6 arrangement -- and an application gets back
whatever it gets back (whether the query is addressed to the
DNS, read off a label on the device and entered manually, or
something else).  If so, then one RRTYPE with the appropriate
identifier in the data is the right answer.

If not... if, for example, different types of applications will
look for only one type-length of identifier and will either find
it or give up (not try falling back to the other because that
would make no sense), then the use of two RRTYPEs is entirely
reasonable.  But, if that is the case and this is going to be
standards track, I expect to see an explanation in the document.
That explanation could be as simple as a statement to that
effect and an example or two of the types of applications that
would use each identifier and/or a reference to IEEE materials
that describe the circumstances under which one example or the
other is used.

I'm not opposed to having two separate RRTYPEs -- I just want to
see the rationale.  And what passes for use cases in the draft
appears to me to be  completely silent on that issue.

Especially since there is an IEEE-defined method for representing
a 48-bit address in the 64-bit format. Now you mention it, why can't
that be used in all cases?

two observations

If you have an iab range the eui label would get inserted in the middle 
of the IAB base value iirc. that sounds sort of appauling to read/decode.


Second it's not just a representation it's an encapsulation (you could 
if you so choose use a mac-48 on an eui-64 supporting link layer 
legitimately using the encapsulation).  I'm sure some ugly bridge device 
that I want nothing to do with will do that some time in the future, it 
does therefore seem slightly desirable to render them as they are rather 
than in some canonical form that is both.

 Brian

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/20/13 8:56 AM, John C Klensin wrote:

--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
 wrote:


...

This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or other indicator in the DATA
field as to whether a 48 bit or 64 bit identifier was present?

the basis for assignment of rr-types is expert review. Whether
the draft advances or not the rr-types have been assigned.

http://tools.ietf.org/html/rfc6895#section-3.1.1

http://www.iana.org/assignments/dns-parameters/dns-parameters.
xml#dns-parameters-3

Joel,

I don't know who the current expert is and, for the moment, am
glad I don't and don't intend to check.  I believe there is
broad consensus in the community that having something as
significant as an RRTYPE documented in the RFC Series is a good
idea.
IETF consensus tends to indicate that is is better to assign new 
RR-types then it is to keep having developers jam these usages into text 
RRs.

  Certainly leaving the reference pointing, long-term, to
an I-D would not be a good idea (and would violate several other
principles).
an ISE submission for documentary purposes would minimal impediment and 
documentary value would be preserved an rr-type assignement might well 
point at an external resource.

However, if

(i) the expert review consists largely of making sure
that the template contains the right information and the
ducks are not obviously out of line rather than a
design/architectural review with at least meaningful
potential for community review of the request, and

(ii) the response to a design/architectural concern
raised during IETF LC is essentially "too late, code
points already allocated", and

IETF LC should be, "can we live with this?" The document has been 
discussed in dnsext and reviews were requested, I was prevailed on to 
take it on as that WG is supposed to be shutting down.

(iii) "Proposed Standard" still does not imply
"recommended" and the alternative to approving the I-D
for that category is non-publication,

then I would like to understand, as a procedural matter, what
the IETF Last Call is about.  Certainly it is not for editorial
review; that is the RFC Editor's job and there are, IMO, no
glaring editorial problems.  If the RRTYPEs have been allocated
and can't be un-allocated and this is in use, then there is
nothing to propose as an individual submission for
standardization: an informational document to inform the
community about what this is about would be both appropriate and
sufficient.

Beyond that, your shepherd's report implies that the issue I
raised may have been discussed and successfully resolved in
DNSEXT.   If that is the case, an explanation in the document
about the tradeoffs and decision would still be appropriate.

Alternatively and especially if there wasn't clear consensus in
DNSEXT, if this really is to be processed as a Proposed
Standard, then a suggestion during IETF Last Call that the IETF
Standard way to represent EUIs in the DNS should be a single
RRTYPE with length/type information in the DATA is still in
order: the community could reasonably conclude that the single
RRTYPE is a better solution, that the single type should be
allocated, and that these two types should be deprecated.   We
have certainly done similar things before with other protocols
and parameters that were already in use before standardization
was proposed from an individual submission.
So, I don't have a  problem philosophically or otherwise with the fact 
that there my be a better solution out there. It takes somebody to do 
that work. The can obviously get an rr-type for that application.


In the use cases associated with provisioning systems I would expect 
that knowledge of media type would drive usage of one rr type or another 
e.g. if you're provisioning 6lowpan/zigbee/802.15.4 devices you probably 
don't have to query for eui48.


john

p.s. I've tried reading your shepherd writeup now in three
different browsers.  It appears to be formatted for extremely
long (paragraph-length) lines, with no provision for automatic
wrapping to fit the page frame.

I can fix that by editing the text. a tool fix for that is forthcoming iirc.

   That means that trying to read
and understand it requires extensive horizontal scrolling, which
is a fairly large impediment and, although I assume
unintentionally, a way to discourage anyone but the most
determined of readers from actually reading it.  May I suggest
that the IESG, on a priority basis, either get the format of
those writeup pages changed so that they wrap appropriately or
that it insist that writeups conform to RFC/I-D norms for line
lengths.

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 5/20/13 7:18 AM, John C Klensin wrote:


--On Monday, May 20, 2013 06:44 -0700 The IESG
 wrote:


The IESG has received a request from an individual submitter
to consider the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
as 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
2013-06-17. 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.

This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it is
large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or other indicator in the DATA field
as to whether a 48 bit or 64 bit identifier was present?
the basis for assignment of rr-types is expert review. Whether the draft 
advances or not the rr-types have been assigned.


http://tools.ietf.org/html/rfc6895#section-3.1.1

http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-3


In addition to saving an RRTYPE slot, my recollection of the
uses of EUI-64 is that an application trying to look up an EUI
may not, in the general case, know whether the device and its
EUI are of the 48 or 64 bit persuasions.  If that is correct, a
single RRTYPE and a length/type indicator in the DATA would
avoid a two-stage lookup and/or unnecessary use of QTYPE=ANY.
The same one RRTYPE model would, with even a modicum of good
design, make transition easier when the IEEE goes interplanetary
or interstellar and discovers a need for EUI-128 (or some other
length > 64).

If there really are significant advantages to having two
separate RRTYPEs that override the considerations above, it
seems to me that the reasoning for doing so should at least be
briefly explained in the document.

 john

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

[joel jaeggli]

On 5/16/13 2:58 PM, Keith Moore wrote:

On 05/16/2013 04:46 PM, Yoav Nir wrote:
The time for asking whether the group has considered making this 
field fixed length instead of variable, or whether RFC 2119 language 
is used in an appropriate way, or whether the protocol is extensible 
enough is at IETF last call. 


Actually the time for asking these questions is long before IETF-wide 
Last Call.  We need widespread review of proposals for standards-track 
documents long before a WG thinks it's finished with those 
documents.   It's a gaping hole in our process.


As a Chair and as an AD I have asked for external and cross area reviews 
of some documents before they were considered for WG acceptance. this 
doesn't apply to all work we processed but it does apply to those where 
we were clear that such input was going to be useful.  One case you can 
see for that today is with capwap extensions that are potentially in 
opsawg.
Fix that problem, and most of the conflicts between IESG and WGs that 
surround DISCUSS votes will go away.
Maybe but I wouldn't take that as an article of faith. You're going to 
get pressure for more changes when fresh eyes review something.

Keith

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

[joel jaeggli]

On 5/16/13 10:01 AM, Dave Crocker wrote:

On 5/16/2013 9:40 AM, Adrian Farrel wrote:

That's a good question Dave.

The community might like to comment.

On the whole, I am told that if an AD weighs in with her comments 
during working

group last call, her fearsome personality may overwhelm some of the WG
participants and she may dominate the WG consensus.


Only women ADs? [1]

But seriously...


If Tiresias prophet of Thebes is in your wg, I'd listen.

Is it possible that the same would happen in IETF last call?


I think that the public sway of ADs on the IETF list is less of a risk 
than on wg mailing lists.  And note that my suggestion has ADs waiting 
to weigh in until community-generated active disagreement with the 
spec, or its passive agreement, has been established.


Early participation AD's weighing in on draft's generally takes the form 
of just another participant unless you're asking for an opinion on a 
process point. wearing different hats on the course of the lifecycle is 
normal imho. opinion at the mic or on the list is not iesg review. The 
sponsoring AD (who is presumably the most involved) is not likely the 
one with the discuss later in the process since they had to do the 
initial review, put it through the ietf last call and then ballot it, so 
fundamentally they should have a document they can live with when it 
gets to that stage.
In any event, the current reality of having an AD weigh in with a a 
process-blocking Discuss is not exactly /under-/whelming...


Simply put:  We are starting with the reality that an AD is going to 
be expressing their opinions.  The question is when and how. It's not 
going to be /less/ intimidating to have it done as a Discuss.


Contrary to some of the mythology that has been expressed about this, 
the frequent reality is that the typical wg goal is to clear the 
Discuss, not really to engage in debate with an AD who is blocking 
document progress.  (I've watched this reality many times over the 
years.)  That is far less healthy than having the AD's concern become 
part of the /public/ review process.




I agree that this would bring the tail forward a little (not a lot).
I don't believe it would reduce AD work-load (which is another issue 
entirely).


Yes, the timing change is small.  But the context change is enormous.


Lastly, I think I disagree with you about "really serious" IETF last 
call
comments coming in the first few days. It seems to me that we also 
get an number


Some, sure.  But I said it was an efficiency hack.  The goal isn't for 
it to be perfect, just helpful.


d/


[1] The question of proper referential language is a continuing 
surprise to me, given that the currently-popular conventions create 
more problems than they solve -- and it's even a question on a PSAT 
preparatory example that I saw yesterday.  There's a pretty 
straightforward alternative that works nearly all the time:


   http://dcrocker.net/#gender

Re: Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice

[joel jaeggli]

On 5/7/13 12:07 PM, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters'
as Best Current Practice

Sponsoring AD here,

Getting feedback on the 5342bis document is important since this is the 
primary consensus call.


Thanks
Joel


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 2013-06-04. 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


Some IETF protocols make use of Ethernet frame formats and IEEE 802
parameters.  This document discusses some use of such parameters in
IETF protocols, specifies IANA considerations for assignment of
points under the IANA OUI (Organizationally Unique Identifier),
provides some values for use in documentation, and obsoletes RFC
5342.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Re: call for ideas: tail-heavy IETF process

[joel jaeggli]

On 5/1/13 2:10 PM, Ted Lemon wrote:

On May 1, 2013, at 5:00 PM, Scott Brim  wrote:

Let's rename "last call" to
something like "IETF review" and stop giving people the wrong
expectations.  Review outside the WG is vital, can be done repeatedly,
and must be done by the whole IETF at least once.

Yup.   The term "last call" is traditional, and I feel a bit of attachment to 
it, but I think your observation here is exactly correct: we ought not to think of the 
IETF last call as the end of the process.

However, that is a bit of a problem, because I think it's fairly rare for documents to 
get additional "review" at last call time.   Changing the name probably won't 
fix that.
It feels like unless something is particularly controversial that the 
likelihood of it getting useful review other than solicited ones during 
last call has actually gone down. If it's fully cooked, and sometime it 
seems that they aren't, that lack of commentary does not indicate 
consensus  or readiness in particular.

Re: Language editing

[joel jaeggli]

On 5/3/13 3:04 PM, Brian E Carpenter wrote:

On 04/05/2013 09:22, Yaron Sheffer wrote:

GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.

I think I disagree, if we can find the knack of effective crowd-sourcing.
We do after all have several hundred native English speakers active
in the IETF, which would mean each one would have to volunteer for
less than one draft per year and we'd be done.
Variously as an individual contributor, shepherd and chair I have asked 
for source text so that I could provide large copy edits which the 
authors could then apply at their leisure. I have also asked for 
volunteers to help with heavy edits. IMHO polishing a document for 
consumption is a very useful form of contribution, which doesn't 
necessarily require either deep technical background in the area or 
personal involvement in the draft.

I don't know how much experience you have with professional editors.
Apart from the RFC Editor crew, my experience has been "mixed". Somebody
a year or three ago (the last time we had this exact same discussion)
pointed out the differences between copy-editors and technical editors.
One difference is that the latter are much more expensive. Copy-editors
tend to be rule-driven; technical editors are supposed to understand
the material.
Most working group participants already have a deeper background in the 
area and familiarity with the jargon than a copy-editor.


 Brian

Re: call for ideas: tail-heavy IETF process

[joel jaeggli]

On 5/2/13 11:14 AM, Hannes Tschofenig wrote:


b) There is no interest to research where delay really happen. Your 
statistics just tell that there is delay but not why (of course). From 
my own experience I noticed that there are many reasons for delay and 
I am not sure I can blame it to the IESG reviews for most of the 
delay. It is only during the IESG review phase when the problems 
surface that could have been tackled much earlier.


Without looking at a number of cases we might focus on the wrong 
issues. Maybe, but I am not sure, there is something that can be 
generalized from some individual cases.


I am happy to work with someone else to go through a couple of 
different IETF activities that did not really go as planned to 
"reconstruct" what went wrong. I suggested this in the past but it is 
of course not fashionable and exciting.


The big delays on documents in my queue (e.g. one's that I inherited) 
are almost exclusively of author or wg holds the token again or blocked 
on some other document variety.  the tail is pretty long, whether it's 
heavy or not for a visibile minority of drafts.

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[joel jaeggli]

On 4/30/13 8:33 AM, Robert Sparks wrote:

On 4/2/13 4:58 AM, Brian E Carpenter wrote:

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:

Hi, Robert

...


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]

...

The document currently references
draft-chown-v6ops-renumber-thinkabout
several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.
[Bing] draft-chown-v6ops-renumber-thinkabout is an important input 
for the gap analysis. Although the draft is expired, most of the 
content are still valid.
draft-chown is a more comprehensive analysis, while the gap draft is 
focusing on gaps in enterprise renumbering. So it might not easy to 
abstract several points as important from draft-chown to this draft. 
We actually encourage people to read it.
Robert is right, though, sending people to a long-expired draft is a 
bad idea.
I'm not sure I see that as worse than referring to Wikipedia, an expired 
draft has the property that it's not going to change. I have no problem 
with the idea that it would be an informative reference.   but yes it's 
a bit much to say go read this.
Of course we have to acknowledge it, but maybe we should pull some of 
its text

into an Appendix.

Tim Chown, any opinion?
The most recent version (and the one slated for the next telechat) 
still has this long-expired draft referenced.


RjS

Re: Sufficient email authentication requirements for IPv6

[joel jaeggli]

On 4/8/13 9:18 PM, Douglas Otis wrote:


On Mar 31, 2013, at 1:23 AM, Doug Barton > wrote:



On 03/30/2013 11:26 PM, Christian Huitema wrote:
IPv6 makes publishing IP address reputations impractical.  Since IP 
address reputation has been a primary method for identifying 
abusive sources with IPv4, imposing ineffective and flaky > 
replacement strategies has an effect of deterring IPv6 use.


In practice, the /64 prefix of the IPv6 address has very much the 
same "administrative" properties as the /32 value of the IPv4 
address. It should be fairly straightforward to update a reputation 
system to manage the /64 prefixes of IPv6. This seems somewhat more 
practical than trying to change the behavior of mail agent if their 
connectivity happens to use IPv6.


That only works insofar as the provider does not follow the standard 
recommendation to issue a /48. If they do, the abuser has 65k /64s to 
operate in.


What's needed is a little more intelligence about how the networks 
which the IPv6 addresses are located are structured. Similar to the 
way that reputation lists nowadays will black list a whole /24 if 1 
or a few addresses within it send spam.


The problems are not insoluble, they're just different, and arguably 
more complex in v6. It's also likely that in the end more work on 
reputation lists will provide less benefit than it did in the v4 
world. But that's the world we live in now.


Dear Doug,

Why aggregate into groups of 64k prefixes?  After all, this still does 
not offer a practical way to ascertain a granularity that isolates 
different entities at /64 or /48.  It is not possible to ascertain 
these boundaries even at a single prefix.  There is 37k BGP entries 
offering IPv6 connectivity.  Why not hold each announcement 
accountable and make consolidated reputation a problem ISPs must 
handle?  Of course, such an approach would carry an inordinate level 
of support and litigation costs due to inadvertent collateral 
blocking.  Such consolidation would be as impractical as would an 
arbitrary consolidation at /48.


Plently of people use IP to ASN mappings as part of their input for 
reputation today.
Prior traffic is required to review reverse DNS PTR records, which is 
resource intensive due to unavoidable delays.  Our IPv4 reputation 
services will not block entire /24s based upon a few detected abusive 
sources.  CIDR listings grow only after abuse exceeds half.   Even 
this conservative approach is problematic in places like China.  There 
are 4 million /64 prefixes for every possible IPv4 address .  Taking 
an incremental CIDR blocking approach still involves keeping track of 
a prefix space 4 million times larger than the entire IPv4 address 
space, where it is generally understood sharing the same IP address 
carries a risk.  Are you really suggesting that sharing the same /48 
carries a similar risk?


The goal should be to avoid guesswork and uncertainty currently 
plaguing email.


v6 BGP announcement growth graph is published at:
http://bgp.potaroo.net/v6/as2.0/

Regards,
Douglas Otis

Re: Less Corporate Diversity

[joel jaeggli]

this late  but I thought I'd comment on one part of it.

On 3/20/13 3:36 PM, Jari Arkko wrote:

I think it is mostly market forces and historical reasons, and the development 
of the IETF to focus on more particular core aspects of the Internet (like 
routing) as opposed to what the small shops might work on.

But I think we are missing a bit of the point in this discussion. I do not feel that we 
need to prove we are somehow "no worse" than industry average. The point is 
that *if* we had more diversity along many of the discussed lines, we'd be far better 
off. For instance, having people from multiple organisations provide input to a last 
would be preferable to just a few. Similarly with the other dimensions of diversity. When 
I talked to some of the ISOC fellows last week, I realised peering is very different on 
different continents.

Different doesn't generally mean good, in the peering case.

There are plenty of examples of monopoly PTTs or regulators engaging in 
behavior that impacts the usability of or availability of traffic 
exchange, there's all sorts of market failures, and there's deliberately 
uncompetitive practices from some of the participants. so when we look 
at the diversity of experience for network operators not all the 
diversity is a happy place.

  Even if there may be less economic activity on networking on those 
continents, it would be good for us to understand the real situations around 
the world, as opposed to thinking the whole world is like where we live. 
Diversity = good in most cases, and increasing that goodness should be the goal.

Jari

Re: On the tradition of I-D "Acknowledgements" sections

[joel jaeggli]

On 3/25/13 1:57 PM, t.p. wrote:

- Original Message -
From: "Melinda Shore" 
To: 
Sent: Monday, March 25, 2013 1:11 AM

We have the mailing list archives, we've got the document shepherd
writeups, we've got the IESG evaluation record, we've got the IESG
writeups, we've got meeting minutes, we've got jabber session
archives, we've got audio recordings of meetings, and we've got the
document history.

And it is not enough. A question arose recently as to why the wording in
an RFC was what it was, what it did intend to mean, and while I could
look at the different versions of the I-D and identify the nine month
period in which the change occurred, from the wording in an earlier RFC
to that in the replacement one, nothing else from that time gave any
clue as to why, nor could any remember.  All we know is who was editing
the I-D at the time in question.
Even if you had svn commits that probably wouldn't answer the question 
of why.


Before one heads down the epistemological rathole, aren't there simpler 
questions to be asked?

Most of the resources you mention are not available from the time in
question so we cannot judge how well we are currently being served until
at some point in the future they are put to the test.  Likely, they will
be found wanting, as our older records have been.

Tom Petch


Melinda

Re: Please review draft-housley-rfc2050bis-00.txt

[joel jaeggli]

On 3/18/13 6:04 AM, Ole Jacobsen wrote:

I am wondering if the draft should mention that Local Internet
Registries (LIRs) may sometimes take the form of National Internet
Registries (NIRs) since this is now a reality in some places?
All of the "NIRs"  I've encountered can be construed as LIRs under the 
terms of the definition of LIR in that region. apnic and lacnic I belive 
specifically recognize the term.

The current text doesn't exclude such an arrangement, but given
that this draft is an update to reflect current reality, it might
make sense to include mention of NIRs explicitly, even if their
mere existent may be considered "controversial."

Or is that just one can of worms you wish to leave unopened?

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

Re: Martians

[joel jaeggli]

On 3/13/13 10:24 AM, Noel Chiappa wrote:

 > Subject: Re: Martians

 > "Martian" is nice expression.

Weren't 'unusual' packets called 'Martians' at some early stage of Internet
work? It certainly has history in the IETF as a term of art, I think that's
it.

http://tools.ietf.org/html/rfc1812#section-5.3.7

Noel

Re: Nomcom off in the wilderness: Transport AD

[joel jaeggli]

On 3/9/13 1:46 PM, Benoit Claise wrote:

I'm really, really against turning this into an election-like process
just because one nomcom did a bad job (and I agree they did).


I've puzzled by this statement "nomcom did a bad job".
How could we, people outside of noncom, know that they did a bad job?
What we know is that it hasn't produced a AD that has been approved by 
the IAB. It's premature at the very minimum and imho probably 
inappropriate to start assigning blame.
They are the only ones who have all the information, all the variables 
in the equation. We don't. So I believe that, at this stage, we can't 
make that assertion.

Being a positive person, I (want to) trust them.

Regards, Benoit

Re: How do they select people

[joel jaeggli]

On 3/6/13 2:06 PM, SM wrote:

Hi Mike,
At 08:44 06-03-2013, Michael StJohns wrote:
I would suggest that it's probably time to re-convene the "how do we 
select people" working group.  Given the number of issues - recall, 
IAOC, this, ineligible others  - we've encountered lately, I don't 
think just cutting and pasting a new RFC over 3777 to patch holes 
makes sense.


There are some issues which may have to be addressed at some point.  
Patching holes creates an incomprehensible BCP.


There are some interesting details in RFC 3777.  I don't know whether 
they have been exercised.  Anyway, the question is about "how do they 
select people".  It has been mentioned previously that:


  "One former chair pointed out that the NomCom moved pretty quickly
   from a model where a random sample of the community selects
   leadership based on personal experience to a model where the random
   sample of the IETF is expected to survey a large and increasing
   percentage of the total community in order to select leadership."

And:

  "It is possible for either the Nomcom or a confirming body  to wedge
   the process in a way where it cannot proceed."

One item which is not mentioned is that public lynching of candidates 
should never be encouraged.
Or the nomcom unless you want to insure that the pool of volunteers 
shrinks in the the future.
The Nominating and Recall Committees have the latitude to get the work 
done.  They are supposed to get the work done. When the selection 
process reaches a point where a working group slot is necessary to 
poke at people who have accepted to work for free, is there something 
wrong.  When an impossible event turns out to be possible, is there 
something wrong?


Regards,
-sm

Re: IETF Challenges

[joel jaeggli]

On 3/3/13 1:51 PM, Michael Richardson wrote:

"joel" == joel jaeggli  writes:

 joel> http://www.arkko.com/tools/rfcstats/countrydistrhist.html

 joel> blue = china grey = japan

 joel> http://www.arkko.com/tools/stats/countrydistr.html

The colours are alas confusing, as they are repeated.
I think the thickness is different, but I can't track to the graph.

What happened between 1972 and 1986? :-)

I'm unclear on the countrydistr.html if this is RFCs or IDs.
I'm guessing it is the same data, so it's RFCs.


data is data, the methodology an tools are described on the website.

http://www.arkko.com/tools/authorstats.html

the country dist graph I pointed to is for drafts.

there are a lot more drafts than RFC's so if you want look at the 
distribution of authorship and it's change over time there's more data 
points in the drafts.

Re: IETF Challenges

[joel jaeggli]

On 3/3/13 4:12 AM, Abdussalam Baryun wrote:

On 03/03/2013 01:37, Melinda Shore wrote:

On 3/2/13 2:42 PM, Fred Baker (fred) wrote:

I'd suggest you redo your analysis. It doesn't have a lot to do with
reality in the working groups I'm in.

I wonder if he's basing this on the main discussion lists.  There
actually don't seem to be that many people from Japan and China
posting here on IETF-discuss, despite considerable activity from
those corners of the globe on individual working group mailing lists.

I think the Internet Community of Japan and China are important to the
IETF, maybe more important challenge to attract them for IETF
purposes. I think the reason is that they my not be posting because
some replies are discouraging in IETF which means there is another
challenge for IETF.

http://www.arkko.com/tools/rfcstats/countrydistrhist.html

blue = china
grey = japan

http://www.arkko.com/tools/stats/countrydistr.html

  I still didn't leave the posting because there are good encouraging
people in IETF. Please note that I have been now one year posting and
two years before reading, and have a feeling that IETF SHOULD
encourage people from China, Japan, Africa,

AB
My Origins from Africa Internet Community

Re: Sunday IAOC Overview Session

[joel jaeggli]

On 3/2/13 8:15 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:

Please let us know ahead of time if you have specific questions you would like
to see discussed.

I would find it as useful if IAOC would have a public maillist, where location 
options could be discussed well before the meeting site decision is taken.
Such a discussion would lead to more stable decisions based on community 
feedback.

Meeting venues are negotiated with under NDA so how you do that?

Cheers,
Mehmet



-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On
Behalf Of ext The IAOC
Sent: Monday, February 11, 2013 11:54 PM
To: IETF Announcement List
Cc: i...@ietf.org
Subject: Sunday IAOC Overview Session

The IETF Administrative Oversight Committee (IAOC) will hold a session from 
1500-
1650 in Caribbean 6 at the Orlando IETF on Sunday March 10.  The purpose is to
provide an overview of the IAOC to allow the community to better understand 
what the
IAOC does, how the finances work, and provide the IAOC feedback on the job they 
are
doing.

The IAOC's responsibilities include:

  - Managing the IETF finances
  - Oversight of the IETF Administrative Director (IAD)
  - Selection and oversight of contracted services
  - Venue selection and operation of the IETF meetings
  - Support for the IETF's IT services (data tracker, web sites,
tools, etc.)

Based on the open mike discussion at the last IETF meeting we think that this
will be a useful way to provide more information to the community than can be
done in the plenary.

The topics that will be discussed include:

  - BCP101 - Structure of the IETF Administrative Support Activity (IASA)
  - Operation of the IAOC
  - Financial model and relationship with ISOC
  - 2012 Financial Summary
  - Q & A

We hope this will improve the community understanding of how the IAOC works and
provide the community an opportunity to provide feedback to the IAOC.  If this 
session
works well we will repeat it periodically.

Please let us know ahead of time if you have specific questions you would like
to see discussed.

Bob Hinden
IAOC Chair

Re: Internet Draft Final Submission Cut-Off Today

[joel jaeggli]

On 2/26/13 2:25 PM, Paul E. Jones wrote:

Dale,


Personally, I'd trust "date -u" much sooner than any random person.
Even better:

 $ date --date='00:00 Feb 26, 2013 UTC'
 Mon Feb 25 19:00:00 EST 2013
 $

Funny thing is when I try the date from the announcement:


All Final Version (-01 and up) submissions are due by UTC 24:00 Monday,

February 25.

I get this:

$ date --date='24:00 Feb 25, 2013 UTC'
date: invalid date `24:00 Feb 25, 2013 UTC'

Seriously, what the heck is 24:00?  Is that like the meeting we'll have in
the afternoon at about 13:90?
The minute which occurs after 23:59 is 00:00 of the following day if you 
have a leap second, you get 23:59:60 which is fun...

Paul

Re: Internet Draft Final Submission Cut-Off Today

[joel jaeggli]

On 2/26/13 11:12 AM, Michael Tuexen wrote:

On Feb 26, 2013, at 8:01 PM, Dale R. Worley wrote:


From: James Polk 

Personally, I'd trust "date -u" much sooner than any random person.
Even better:

$ date --date='00:00 Feb 26, 2013 UTC'
Mon Feb 25 19:00:00 EST 2013
$

Requires a Unix like system...
Finding the current time in UTC could reasonably  be left as an exercise 
for the reader...

Dale

Re: Internet Draft Final Submission Cut-Off Today

[joel jaeggli]

On 2/25/13 5:02 PM, Mark Nottingham wrote:

Don't think so:

mnot-mini:~> date -u
Tue 26 Feb 2013 01:01:29 UTC


On 26/02/2013, at 11:58 AM, James Polk  wrote:


At 06:50 PM 2/25/2013, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/25/13 5:47 PM, James Polk wrote:

The ID upload tool says the deadline has passed, yet a decade or
more the deadline has been 8pm ET/5pm PT. That's 15 minutes from
now.

I had the same problem last week for the -00 cutoff.

It used to be 5 PM Pacific, now it's 24:00 UTC.

It's always been 2400 UTC, but with all the daylight savings time adjustments 
from country to country changing from year to year, I have talked to the 
Secretariat before (and recently), and verified this is indeed 8pm ET, at least 
for those in the US.
Between march 10 and November 3rd DST applies in the USA. Outside that 
midnight UTC is 1600 Pacific.

James



Peter

- --
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRLAbrAAoJEOoGpJErxa2pJCQQAK05V61dUleo5z+nsodQPNCn
Lt98t7543ic48vaYHpwCYv4zT7sbCJ9KJ7bm0gqBHwnsRnUvb2qeLfQTrBGpKHLG
ZFLiIVDoTqJjEKzcGoEv6ZupZADjiZZZxAN0c+0o2NWJJFs5Jt1x/88k4fmAPGpo
qUGOAUdaQ+ayD4qPYysSiexAJ4kj4x2oSjqWK9SQXJ2LX816mI6YIY75BxF/HniE
Hz95w05hVS6h1LNpr5O0DlY44pUHrBEi4jxXF7GVPhA/XvBS1ONRlbWVBz/tsURG
SJ1HXkKOWpKegld6HjllqjvkSXIEKcs/xc5L68+pkOmdySQ7SQxl0WBqIXDv0Yul
t82W5gUxgkX0XpDE5+SQ3npuseCY77q9HzN3XkzZA1HWTcSMPIUEY7PhgWmuSms6
/aH46hBLVJhOAWDSNieG+lfnJahlvrmTUcZ5l/JJo/AeTbK+cxY8a0NDVit+pi2P
wS8XKBuyM5Z1BxqxtozmDAU1HP3qhTt+m/tBNPNkN185MSylDlnWZQVbZ+ZjH5Jq
LrO9ELqyPC6Evq0j4V4pltOs0T7yVMw7XFWKZv/cVjkC7fu6ZZ3inMovnjmHfQe/
H+ItSqZuHLMOBuFjioPskdujLWadIt1vpULjsw5tdaton82sruaqIC0NdSh7Sr7C
hKLwIVutjXHVvW7b5kzC
=60kr
-END PGP SIGNATURE-

--
Mark Nottingham   http://www.mnot.net/

Re: Fwd: I-D Action: draft-barnes-healthy-food-06.txt

[joel jaeggli]

On 2/25/13 10:36 AM, Mary Barnes wrote:

In light of the upcoming meeting in Orlando, I have updated the
document.  For folks that are not on the IETF-86 attendees list, we've
had a fairly lengthy discussion about the remoteness of the venue and
the lack of access to food other than the hotel restaurants that are
often mediocre and over-priced.   For folks that aren't familiar, this
document has recommendations for meeting planners and IAOC folks in
terms of selecting venues that can ensure that IETF participants have
access to the types of food they require during the meetings.   Lunch
is often the biggest challenge due to frequent lunchtime meetings and
the volume of people requiring lunch at the exact same time.

I wrote this document right after the IETF meeting in Dublin (almost 5
years ago) and given the Orlando venue selection (which occurred after
the Dublin meeting) it does not seem to me that the requirements and
recommendations in this document are being considered as serious input
to that process.   While I am the most vocal with regards to this
issue, it isn't just me - others just don't want to be the target for
the types of discussions we inevitably have on this topic.
fwiw I generally support documents that encourage a consistent and 
repeatable approach to meeting requirements and which assigns 
responsibility to the participants as well, and I would probably support 
this document.


One observation though. The introduction:

  While much of the success of IETF protocols can be attributed to the
   availability of large cookies and readily available beer, there are
   some IETF participants for whom such items aren't compatible with
   dietary restrictions or the choice to eat a healthy diet.


A significant contributor to the complaints about breaks without snacks 
and indeed "cookies" is hypoglycemia and there the snack/cookie issue 
should be seen in that light. Big cookies is clearly a trope, in the 
context of plenary dicussion, but low blood sugar is not.



   I will
note that if we were discussing wheel chair accessibility to IETF
meetings, most folks would understand the concern.  In the US, medical
conditions that require special diets are considered hidden
disabilities and the same legal requirements apply in terms of those
diets being accommodated.   While IETF is a non-profit, my
understanding is they have no legal requirements to provide the
accommodations, one would expect such as part of the nature of IETF in
terms of being an open and inclusive organization.

I will note that there have definitely been improvements since Dublin,
including the fruit bars when we have Ice Cream Thursdays and the
secretariat always communicates requirements when they are made aware
(e.g., WG chairs luncheon, as well as IAB stuff).  ISOC has also been
accommodating for their Tuesday lunch sessions.   As an aside while
I'm on the food topic, I didn't learn until last IETF that we don't
have Ice Cream Thursdays unless someone sponsors it.  Since I was
highly disappointed at the Atlanta meeting, I was able to get Polycom
to sponsor the event at IETF-86 ;)

At this stage, the feedback I would like related to this document is
with regards it's readiness for publication as an RFC.  One of the
updates to the document was with regards to the references to other
IETF logistic documents (the Tao and the travel FAQ) which have since
been published.  I believe this document is equally substantive and
applicable to the IETF as those documents.

Regards,
Mary


-- Forwarded message --
From:  
Date: Mon, Feb 25, 2013 at 12:18 PM
Subject: I-D Action: draft-barnes-healthy-food-06.txt
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


 Title   : Healthy Food and Special Dietary
Requirements for IETF meetings
 Author(s)   : Mary Barnes
 Filename: draft-barnes-healthy-food-06.txt
 Pages   : 18
 Date: 2013-02-25

Abstract:
This document describes the basic requirements for food for folks
that attend IETF meetings require special diets, as well as those
that prefer to eat healthy.  While, the variety of special diets is
quite broad, the most general categories are described.  There can be
controversy as to what constitutes healthy eating, but there are some
common, generally available foods that comprise the basis for healthy
eating and special diets.  This document provides some
recommendations to meeting planners, as well as participants, in
handling these requirements.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-barnes-healthy-food

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-barnes-healthy-food-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-barnes-healthy-food-06


Internet-Drafts are also ava

Re: presenting vs discussion in WG meetings (was re:Remote Participation Services)

[joel jaeggli]

On 2/16/13 12:04 AM, Brian E Carpenter wrote:

On 15/02/2013 20:57, Keith Moore wrote:
...

But this makes me realize that there's a related issue.   An expectation
that WG meetings are for presentations, leads to an expectation that
there's lots of opportunity to present suggestions for new work to do.
WG time scheduled for considering new work can actually take away time
for discussion of ongoing work.   And once the time is scheduled and
people have made commitments to travel to meetings for the purpose of
presenting new work, chairs are understandably reluctant to deny them
their allotted presentation time.
In v6ops we require that scheduled material to be discussed in the 
meeting have been aired out on the mailing list first. That is a rather 
good filter for which discussions about new work should be accepted. The 
time between meetings is ultimately a lot more scalable and less 
precious than the time during meetings. while there is certainly the 
opportunity for WG discussion to go where it needs to, one does not plan 
a trip to the IETF on the basis of impromptu MIC time.

This is closely related to a well-known problem at academic conferences.
Many people can only get funded to travel if they are presenting a paper.
It's common practice, therefore, to have either a poster session (which
allows massively parallel presentations) or hot-topics sessions (with a
strict and very short time-limit). We tend to throw the hot-topics sessions
into WG meetings, which is not ideal.
There is literally no editorial barrier to the submission of an internet 
draft. Moreover the typical basis for the dicussion of an idea on a 
mailing list or in a WG meeting is that it exists as an internet draft.


Why not have a poster session as part of Bits-n-Bites? It would give
new ideas a chance to be seen without wasting WG time. Make it official
enough that people can use it in their travel requests.

 Brian

Re: Remote Participation Services

[joel jaeggli]

On 2/11/13 5:17 PM, Keith Moore wrote:

On 02/05/2013 11:04 AM, IETF Chair wrote:

3.4. Slide Sharing

Slides are often sent by email in advance of the meeting.
WebEx allows the slides and desktop applications to be viewed 
by the

remote participants.  These are controlled by the presenter.  The
presenter can be shifted from participant to participant as needed.



Can we *please* discourage the habit of treating IETF WG meetings as 
one series of PowerPoint presentations after another?   This makes the 
meetings much less productive.


The notion that there are supposed to be slides for each presentation, 
is IMO, a huge error.
If you have prepared materials for your segment of the agenda they 
should be available beforehand, full stop.


If you don't, then I imagine they won't be. you're depriving some of 
participants who may not be familiar with your work the opportunity to 
review what you want to discuss. but that's between you and your working 
group chairs.


Keith

Re: The RFC Acknowledgement

[joel jaeggli]

On 2/11/13 3:32 PM, Abdussalam Baryun wrote:

On 2/12/13, joel jaeggli  wrote:

Do you mean that IETF is producing what it does not own, or IETF has
no right to edit/amend a document that it is publishing? I
misunderstand your point,


Once an RFC number is issued  and the document published, the content of
that RFC never changes.

See RFC 2200 section 2


I agree, but still IETF can update or obsolete any document,
A consensus driven working group process can be used by IETF 
participants to produce a new RFC which updates or obsoletes an existing 
document. The existing document does not change.


ftp://ftp.ietf.org/rfc/rfc822.txt looks the same as in 1982.


The question ment to be:
Do you mean that IETF is producing what it does not own, or IETF has
no right to edit/amend a document that will be published?
Authors grant rights under the terms of the provisions in force at the 
time of publication. Not some unspecified set of rules in the future. So 
variously none, 1310, 1602, 2026, 3978, 4748 and the IETF Trust 
Licensing Policy.

AB

Re: The RFC Acknowledgement

[joel jaeggli]

On 2/11/13 2:34 PM, Abdussalam Baryun wrote:

Hi SM,

thanks for your email, my reply inline;

On 2/11/13, SM  wrote:

Hi Abdussalam,

Eric Burger provided some information about acknowledgements in a
message at
http://www.ietf.org/mail-archive/web/ietf/current/msg77076.html  Fred
Baker shared his perspective in a message at
http://www.ietf.org/mail-archive/web/ietf/current/msg71104.html

I agree with them and never disagreed, I just gave a point of view,


At 23:47 10-02-2013, Abdussalam Baryun wrote:

Then from your opinion to be fare, I RECOMMEND that the RFC-section
SHOULD be changed to *Authors' Acknowledgements*. Please note that the
RFC is owned by the IETF so the section of ACK should not be only
thanks of the authors or editors or Chairs, otherwise SHOULD be
mentioned in title. IETF considers all inputs related to I-D as a
contribution, please read the NOTE WELL. So do we understand that IETF
is impolite with some of its contributors/workers?

I don't see anything in RFCs to point to the fact that "the RFC is
owned by the IETF".  The Note Well is about keeping the lawyers
happy.  I don't see what it has to do with impolite.  If your name
has been missed in the Acknowledgements Section you could send a
message to the author, with a copy to the document shepherd, about that.

Do you mean that IETF is producing what it does not own, or IETF has
no right to edit/amend a document that it is publishing? I
misunderstand your point,

Once an RFC number is issued  and the document published, the content of 
that RFC never changes.


See RFC 2200 section 2

Re: Remote Participation Services

[joel jaeggli]

On 2/5/13 8:04 AM, IETF Chair wrote:

Please see the attached report on the current status of remote participation in 
the IETF meeting.  Please notice at the end a call for potential experiments to 
explore ways that we can improve remote participation.
Thank(s) for doing the summary,  I believe understanding what is 
currently done and what has been done in the past is an important point 
for dicussion to jump off from.


An important consideration imho when the services were volunteer 
supported (as meetecho still is) is that they were relatively scalable 
relative to some previous iterations. audio streaming for all meeting(s) 
in parallel can be run by one person who has other responsibilities and 
little involvement from inroom participants. bidrectional conferencing 
typically involves more effort.


2.2. Video

In the 1990s as part of the multicast experiment, multicast video was
made available, but this experiment has ended without evolving into a
production service.
The service was offered really in two phases,  one in which 
bidirectional workstation concerning tools were used on both ends


vic/vat/sdr/wd

and bidirectional participation was possible. (archives were in rtp format)

and a phase through approximately the end of 2004 where streams were 
sourced in one direction.


in either case the potential audience was limited by the availability of 
ip multicast at a location.


expired version of the draft covering that time was:

http://www.watersprings.org/pub/id/draft-jaeggli-ietftv-ng-01.txt

As part of a separate experiment, some sessions use Meetecho to make
video available to anyone with a web browser.  WG Chairs must request
this coverage.  When Meetecho is used, the URLs are announced in
advance, and the recording becomes part of the session proceedings.

Re: History of protocol discussion or process in WG

[joel jaeggli]

On 2/3/13 1:23 PM, Nick Hilliard wrote:

On 03/02/2013 21:17, joel jaeggli wrote:

Having responded to an appeal associated with handling of a WG document,
there can easily be 2000k worth of messages sitting in the archives arcoss
multiple lists for a given document.

I forsee many phds for future anthropologists and social historians.
I know somebody who reconsidered the wisdom of doing a master's thesis 
that involved the RSVP WG process.

Nick

Re: History of protocol discussion or process in WG

[joel jaeggli]

On 2/3/13 1:04 PM, Scott Brim wrote:

On 02/03/13 11:29, "Lixia Zhang"  allegedly wrote:


I believe what AB suggested is a historical record specifically for each
WG: what you started with, what you went through, how you ended, what you
have learned, both principles and lessons.

90% of that is meeting notes.  Everyone keeps good meeting notes, right?
(:-p).  The rest, well, the chairs could write it at WG closure and
probably not get any significant complaints.
Having responded to an appeal associated with handling of a WG document, 
there can easily be 2000k worth of messages sitting in the archives 
arcoss multiple lists for a given document.

Re: A modest proposal

[joel jaeggli]

On 1/23/13 1:27 AM, Hannes Tschofenig wrote:

Hi Brian, Hi Joel,

the point of my mail was not to start a discussion about the examples I provided but to 
note that the suggested "let's reduce complexity by reducing options" is not as 
easy as it sounds in practice.
The prototypical human enterprise has need to innovate which means 
finding a way to bring products and services which people want buy to 
market. This process is both one of discovery and failure (market 
signals). Part of the process which respond(s) in an inverse fashion to 
market signals is effort required for standardization (e.g. increased 
demand and therefore resources makes it harder not easier). It is is 
relativity easy at the margins to wing documents for things which nobody 
really cares about through the IETF (one can contrast this with other 
standardization processes if you like), the result being that you have a 
record of a diversity of lightly used but possibly important to someone 
or potentially no-one solutions. When you have a great number of groups 
involved in the development of what is currently a hot area of work, the 
amount of effort associated with getting those drafts through a  process 
is dramatically larger, they are subject to evolutionary pressure, and 
they have to satisfy the needs of a great number of constituents, that 
probably if not always produces a better outcome as far as utility, and 
interoperability as concerned but the efforts at the margins don't stop 
because of it.

In the context of the document Stephen wrote and the proposal that was made on 
the list I was wondering whether a bit more analysis about what the problems we 
are trying to solve would be helpful. As some folks had raised implementing 
specifications is not a sufficient condition for interoperability, or 
successful deployment. I personally believe that IETF working groups are a fine 
job in writing code along with their specification work.

Ciao
Hannes

On Jan 23, 2013, at 9:58 AM, Brian E Carpenter wrote:


On 23/01/2013 04:14, joel jaeggli wrote:

On 1/22/13 12:34 AM, Hannes Tschofenig wrote:

Another example from a different area: Why do we need so many
transition technologies for the migration from IPv4 to IPv6? Wouldn't
it be less complex to just have one transition mechanism?

You mean no transition mechanisms...

That was, in fact, the plan (dual stack during coexistence).
It went wrong.

  Brian

Re: A modest proposal

[joel jaeggli]

On 1/22/13 12:34 AM, Hannes Tschofenig wrote:
Another example from a different area: Why do we need so many 
transition technologies for the migration from IPv4 to IPv6? Wouldn't 
it be less complex to just have one transition mechanism?


You mean no transition mechanisms...

Re: A modest proposal

[joel jaeggli]

On 1/22/13 8:29 AM, Janet P Gunn wrote:


Do none of you know what the phrase "a modest proposal" refers to?

We should kill and eat more internet drafts before they  reach one year 
of age.

Try googling it.

Janet


ietf-boun...@ietf.org wrote on 01/21/2013 11:57:22 PM:

> From: William Jordan 
> To: ietf@ietf.org
> Date: 01/22/2013 12:01 AM
> Subject: A modest proposal
> Sent by: ietf-boun...@ietf.org
>
> I've recent had to write a program to interface with a SIP lync
> server and in doing so have had to code to several rfcs.  After
> reading and dealing with implementation of the various rfcs I have
> read I have come up with what I consider "A modest proposal" to fix
> some of the problems I've seen with implementing a rfc.  I think
> anyone who writes a rfc should have to provide a working ANSI/C or
> GNU/C implementation of the rfc in question.  Specifically, I have
> worked with the SIP rfc (rfc 3261) and have come to the conclusion
> that whoever wrote the rfc has never coded a day in their life.
>  Whoever thought it was a good idea to allow multiple ways of doing
> the same exact thing would hopefully be deterred by actually writing
> code to do it.  I think a suitable punishment for those people would
> be to write each way of writing a from header on a blackboard 100
> times... this would actually be less of the pain they've cause by
> making each writer of a SIP stack handle each possible way of doing 
things.

>
> Anyways, that is my modest proposal, please respond or I will be
> forced to reply every day to this mailing list on each and every way
> the SIP spec sucks one email at a time.  FYI I'm not sure if GNU/C
> is the correct acronym, maybe its POSIX/C.
>
> Regards,
> Bill 

Re: Simplifying our processes: Conference Calls

[joel jaeggli]

On 12/4/12 12:28 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Hi Brian,



The point is that we work in public, so the whole community should
know.

Working group mailing lists are also public.



I regularly attend WG meetings where I am not subscribed - it's one of
the
side benefits of the week-long meetings - and who's to say that I might
not
want to drop into OAuth too?

Are you talking about IETF meetings? I am talking about conference calls here.

Are you regularly joining conference calls of working groups where you are not 
subscribed to the mailing lists?


I belive you're drawing a distinction between conference call and 
virtual interim which does not presently exist. It could, but doesn't.





Suppose I happened to notice (I am making this up) that the foobar WG
has
decided to use the IPv6 Flow Label for an unintended purpose? I'd like
to know if they are going to have a conf call, so that I can explain
RFC 6437 to them. Otherwise, I have no interest in foobar.

How would you find this out from the announcement of the conference call given 
that the agenda does not have to announced at the same time? (unless you join 
every conference call to figure out whether there is something of interest for 
you?)

Ciao
Hannes

Re: Useful slide tex (was - Re: English spoken here)

[joel jaeggli]

On 12/2/12 8:08 PM, Randy Bush wrote:

I'm unclear on how we'd carry on a discussion without a floor
management discipline.

i know it's a leap, but maybe presume people are adults

and that everyone of them has a microphone

so we build our meetings around the fears, will someone speak
unacceptably, will someone appeal, will someone pass gas in
class?  next we can have the tsa screen people at the door.
currently we don't do it that way (hand everyone a mic) because it's 
infeasable.  Oddly I have none of the above fears.

can we please play the upside.  there is a high road, let's
take it.


I thought I was. Mic discipline exists because, we have big rooms that require 
sound reinforcement, and remote participants and a recording. So if you're 
concerned about being heard, or hearing or the historical record, you should be 
in favor of it in general

I've never noted the existence of a mic line at an IETF precluding 
statements which I find disagreeable, so I have trouble imagining them 
being used for that purpose.

randy

Re: Useful slide tex (was - Re: English spoken here)

[Joel jaeggli]

On 12/2/12 19:52 , Randy Bush wrote:
>> I'm unclear on how we'd carry on a discussion without a floor management
>> discipline.
> 
> i know it's a leap, but maybe presume people are adults

and that everyone of them has a microphone

Re: Useful slide tex (was - Re: English spoken here)

[Joel jaeggli]

On 12/2/12 19:02 , Keith Moore wrote:\
>>
> I saw very little productive discussion happening in Atlanta in the vast
> majority of working group meetings which I attended.  True, there were
> times when people queued up at the microphones.  (though that's actually
> a pretty inefficient way to have a discussion.) 

I'm unclear on how we'd carry on a discussion without a floor management
discipline.

Shouting?

If the case is that you're in a room with 200 people and you have people
listening remotely, then fundamentally more discipline is required then
if you have 20 people around a table.

Re: Useful slide tex (was - Re: English spoken here)

[joel jaeggli]

On 12/2/12 11:15 AM, Keith Moore wrote:

On 12/02/2012 01:46 PM, joel jaeggli wrote:
We have non-native english speakers and remote participants both 
working at a disadvantage to follow the discussion in the room. We 
should make it harder for them by removing the pretext that the 
discussion is structured around material that they can review and 
follow along on? I don't think that's even remotely helpful.


In general, the purpose of those meetings is *discussion*, not 
presentation.   I'm all for exploring better ways to facilitate 
*discussion* among the diversity of IETF meeting attendees.  But our 
experience with use of previously-prepared PowerPoint presentations to 
facilitate *discussion* shows that use of that tool, in that way and 
for that purpose, is a miserable failure.
Since you and I attend a significant number of the same working groups 
we should have some shared experience, but I'm going to flat out 
disagree. It's possbile that we had completely different experiences in 
the same meetings, but I do firmly believe that slides are facilitatiing 
both the speakers coverage of the problems they're trying to address, 
and the participants dicussion of the problems enumerated.


As a chair one should be engaged in some editorial oversight of the 
contents of slides.
Of course I'd encourage speakers to make available for download 
summaries of the material to be discussed in advance of the meeting, 
for the benefit of non-native English speakers and others. PowerPoint 
(or better, PDF of material prepared in PowerPoint) seems like a 
reasonable format for that.


the reflexive reference to a particular tool isn't a helpful point of 
this discussion imho... It doesn't matter to me what format the slides 
are in so long as these serve to structure the conversation. Powerpoint 
is a tool (and one I don't use), there are plently of others that can 
serve to get the point across.  If a state diagram benefits from 
animation, then you should pick the appropiate tool. whichever tool it 
is the assumption is that the output will be projected and potentially 
displayed remotely. The import conceit, imho is that the material is 
prepared prior to the meeting so that it can be distributed (and this 
may be the point of actual contention for you).
I also think it would be quite helpful to arrange for the topics 
discussed and points raised in the discussion to be displayed in the 
room in real time, as they are typed.   This would provide non-native 
speakers with visuals similar to what they see now with PowerPoint, 
but without the undesirable side-effect of coercing discussion time 
into presentations.   This would also reinforce the need for a 
minute-taker and help to keep the minute-takers honest.
This is a meeting workflow change, I can think of several ways to 
approach it. as with note taking, jabber scribing and managing remote 
participants it requires someone to do the work (though it may overlap 
with one of the other activities).


(I doubt that PowerPoint is the best tool for this purpose, since it 
would be highly desirable to convey the same information, at the same 
time, to remote participants.)


it would be helpful abstract the tool dicussion away from particular 
applications, at the heart of the problem, is not which text/media 
formatting application is used.

Keith

Re: Useful slide tex (was - Re: English spoken here)

[joel jaeggli]

On 12/2/12 10:06 AM, Keith Moore wrote:

On 12/02/2012 12:57 PM, Dave Crocker wrote:



On 12/2/2012 9:51 AM, Keith Moore wrote:

I think you're missing the point.   The core problem is the overuse of
presentations, and presentation tools, for working group face to face
meeting time which is better suited for discussion.



stop blaming the tool.  focus on the folks doing the speaking.
The tool is a big part of the problem.  The tool encourages a certain 
style of interaction that is generally inappropriate for face to face 
working group meetings.




We have non-native english speakers and remote participants both working 
at a disadvantage to follow the discussion in the room. We should make 
it harder for them by removing the pretext that the discussion is 
structured around material that they can review and follow along on? I 
don't think that's even remotely helpful.


Of course, strictly speaking, the focus is on the people who are using 
the tool, and more broadly, on using the habit and community 
expectation that keeps encouraging people to use a poorly suited 
tool.  But they're using the tool poorly precisely because it's very 
difficult to use that tool well for that purpose.   A different 
toolset, (e.g. pens and paper and overhead cameras coupled to 
projectors), would likely produce better results if that toolset did 
not encourage laziness in preparing materials to facilitate discussion.



Keith

Re: "IETF work is done on the mailing lists"

[joel jaeggli]

On 11/27/12 10:00 AM, Barry Leiba wrote:

On Tue, Nov 27, 2012 at 12:25 PM, Dale R. Worley  wrote:

That attendance showed me that most of the IETF meeting was a
waste of time, that it was e-mail that was the main vehicle for work,
and I think that the IETF web site has it about right when it says

This is all true.  Any decision come to during a meeting session must
be reviewed and approved on the WG mailing list.  The reason for this
is to ensure that one can participate completely *without* attending
the meetings and paying the associated expenses.

This brings up a question that I have as an AD:

A number of times since I started in this position in March, documents
have come to the IESG that prompted me (or another AD) to look into
the document history for... to find that there's basically no history.
  We see a string of versions posted, some with significant updates to
the text, but *no* corresponding mailing list discussion.  Nothing at
all.
There are v6ops wg documents that have arrived in the IESG  queue with 
more than 1000 messages associated with them... I'm not sure that is 
indicative of any entirely healthy wg mailing list process but it does 
leave behind a lot of evidence.


even if all these things were healthy it seems like the actual outcomes 
would be wildly divergent given varying levels of interest.



  The first we see of the document on the mailing list is a
working group last call message, which gets somewhere between zero and
two responses (which say "It's ready."), and then it's sent to the
responsible AD requesting publication.

When I ask the responsible AD or the document shepherd about that, the
response is that, well, no one commented on the list, but it was
discussed in the face-to-face meetings.  A look in the minutes of a
few meetings shows that it was discussed, but, of course, the minutes
show little or none of the discussion.

We accept that, and we review the document as usual, accepting the
document shepherd's writeup that says that the document has "broad
consensus of the working group."

So here's my question:
Does the community want us to push back on those situations?  Does the
community believe that the real IETF work is done on the mailing
lists, and not in the face-to-face meetings, to the extent that the
community would want the IESG to refuse to publish documents whose
process went as I've described above, on the basis that IETF process
was not properly followed?

I realize that this question is going to elicit some vehemence.
Please be brief and polite, as you respond.  :-)

Barry, Applications AD

Re: Newcomers [Was: Evolutionizing the IETF]

[joel jaeggli]

On 11/14/12 7:39 PM, Arturo Servin wrote:

  Also, for it
would be good for the ietf community know, see and live other realities,
different needs, and perhaps more constrained that the normal that we
used to.

Regards,
as


I have not contributed to the IETF activity since the 44th meeting 
because I wanted the participants to suffer. The goal of the volunteers 
and paid staff in various roles is to make the meeting successful not 
add hardship. It's hard enough already.


joel

Re: Newcomers [Was: Evolutionizing the IETF]

[joel jaeggli]

On 11/11/12 3:59 AM, Abdussalam Baryun wrote:

  I don't think that thoes Canada and US participants are paying for
the attendance, but their organisations, therefore, are we reducing
the cost of other organisations, or we are interested to bring more
participants.

Many participants, myself included are footing our own bill for attendance.

Re: Newcomers [Was: Evolutionizing the IETF]

[joel jaeggli]

On 11/9/12 8:00 PM, Arturo Servin wrote:

Brian,

 Your comment just reinforce my perception that the IETF is not
interested in being an global organization of standards.

 People is asking how to evolve the IETF, well, one possibility is to
start thinking global and to reach more people outside the common
venues. It is more expensive, more complex, yes. But in my opinion is
worthy if we really want to show that we care about the multistakeholder
model that we preach.
Multistakeholder is a loaded term from other contexts. IETF participants 
whether they attend the meeting or not are self-selected.


I have some thoughts about interim meetings as an outreach tool in draft 
form and I would appreciate some feeback on those sections.


http://www.ietf.org/id/draft-jaeggli-interim-observations-03.txt

 Hard times may come, some people will ask why the Internet standards
are just developed in some places and will challenge us. Frankly, what I
see is that we do not care.
Why shouldn't standards be developed elsewhere (oddly enough, they are)? 
IETF participants have never had a monopoly on either need or good ideas.


 Regards, as On 09/11/2012 19:50, Brian E Carpenter wrote:

Arturo,

On 09/11/2012 23:26, Arturo Servin wrote:

So basically the IETF is roaming most of the time in  North America,
sometimes in Europe and once in a while in Asia. Is that how the IETF
thinks about the global development of Internet standards?

No. The criterion has always been to hold meetings where they can be
most effective in making the Internet work better - as far as a
standards organisation can do that. That means choosing places where
a meeting can be run effectively and a reasonably high proportion
of those actively participating can afford to attend. As participation
in the IETF has evolved, so has the geographical part of site selection
policy evolved, as Fred described. For example, the attendance data will
tell you why the policy has recently led to two meetings in China.

I think you'll find the policy is different for more operational
meetings, which as far as I can tell have been taking place in Asia,
Africa and Latin America for years. Those meetings have different
criteria for their part in making the Internet work better.


No wonder why some countries in Africa and Latin America are
approaching ITU.

ITU-T does a great deal of its standards-making in Geneva. The meetings
in other areas tend have a different purpose, as do many ISOC activities.


If the IETF really wants to make a change we need to stop thinking that
North-America/Europe = Global.

I think nobody has thought that for at least 10 years (IETF 54).

 Brian

Regards,
as

On 09/11/2012 16:05, Fred Baker (fred) wrote:

On Nov 9, 2012, at 12:28 PM, SM wrote:


At 06:31 09-11-2012, Abdussalam Baryun wrote:

I am newcomer and not able to attend because most of meeting in
America instead of Europe.

Most of the money comes from North Americans.  There is some historical 
information in RFC 3717.

I'd suggest a more thorough analysis.

Data from https://www.ietf.org/meeting/upcoming.html and
https://www.ietf.org/meeting/past.html. Take a look at the attached
spreadsheet.

IETF demographics and meeting location policy have changed over time.

Originally, in 1986, not only was the IETF entirely American, it was
entirely US Government, and nobody else was invited. That changed pretty
quickly, but the community attending remained predominantly US for some
time. So meetings before 1993 all occurred in North America, and if
truth be told, the reason that the meeting in August 1990 was outside
the US was that it had been intended to be in Seattle, the host had a
problem, and UBC came to the rescue.

Starting in 1993, we noted that the demographics had changed; about one
in six IETF participants came from Europe. So, we tried to place one
meeting in six in Europe. We had a small group attending from Australia,
and in 2000 had a meeting there in recognition of the fact. But by that
time, we were starting to have a more significant attendance from Asia,
notably Japan. So we changed policy to trying to position three meetings
in six in North America, two in Europe, and one in Asia+Australia. And
starting (IIRC) in 2005, we simplified that policy to having one meeting
each year in Asia, Europe, and North America.

Regarding that last policy, we have unfortunately had some problems; one
meeting that we intended to have in Asia recently fell through, and we
had to move it somewhere, and in another recent case the Asian venues we
were looking at essentially priced themselves out of the market. Our
Asian friends told us that a meeting in Vancouver was an acceptable
compromise; getting a visa wasn't as hard for them as a US visa, and it
was not too hard to get to. So we have had at least two meetings in
Vancouver that we fully intended to have in Asia.

Since 2004, we have in fact had about 1/3 of our meetings in Europe. If
anyone has 

Re: Evolutionizing the IETF

[joel jaeggli]

On 11/8/12 8:12 AM, SM wrote:

Hello,

I was given the following link at the plenary: 
http://iaoc.ietf.org/documents/IANA-ietf85-nov2012.pdf  and it turned 
out to be a 404.  Could the IAOC please fix the link?


According to the the IAOC report there was one large interim meeting 
where 38 people attended onsite and 23 attended online. The event 
resulted in a US$ 18,000 loss.  Can someone comment on what WG 
progress was made [1]?

I wrote a draft summarizing my experience of the LIM.

http://tools.ietf.org/html/draft-jaeggli-interim-observations-03

Given an attendance fee of $100, and an expected attendance of ~70-100 
the expenses were essentially cooked into the experiment from the outset 
in my understanding.
There is a direct contribution of US $2.2 million by the Internet 
Society next year.  Is the plan to rely on Internet Society subsidies 
or to fix the deficit?  One argument made was that the fees have not 
been increased over the last years.  I'll point out that there hasn't 
been significant increase in paid attendance over the years.  Either 
the IETF is only relevant to the usual folks or else the meetings are 
not made relevant enough for (new) people to attend.


I read http://www.rfc-editor.org/rfc/IETFreports/ietf85.pdf  It's the 
usual reporting from the RFC Editor.  I would like to suggest posting 
that report a week before the meeting so that people can read it if 
they have the inclination to do so.  I gather that after the RFCFORM 
side-meeting which started with the usual discussion about what to 
discuss about, the *SE have understood that they should not negotiate 
with terrorists. :-)  It would be refreshing if the *SE could "think 
outside the box" and share their thoughts about the RFC Series with 
the community and comment on how they intend to reach out to the 
audience which do not attend IETF meetings.


The IAB report is the usual fare.  Why can't this be posted one week 
before the meeting?  The report mentions several drafts and the number 
of open issues.  That's not interesting.  How about picking one issue, 
explain the IAB angle and select someone who has provided feedback on 
the draft to comment?


NomCom posted the list of candidates for an area to a public non-IETF 
mailing list.  This is a departure from past practice [2].


Harald Alvestrand mentioned IETF 55 [3].  Some people might find the 
slides interesting.


Regards,
-sm

P.S. The audio quality was bad.

1. http://www.ietf.org/mail-archive/web/ietf/current/msg75244.html
2. 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07929.html

3. http://www.ietf.org/proceedings/55/slides/plenary-2/index.html

IETF Plenary streaming. - Is originating out of ballroom C

[joel jaeggli]

Since we apparently failed to link it in the agenda.

http://ietf85streaming.dnsalias.net/ietf/ietf852.m3u

1600-1945 EST IETF Operations, Administration, and Technical Plenary - 
Grand Ballroom C/D


Sorry
Joel

IETF85 Streaming Reminder

[joel jaeggli]

Greetings,

For those interested in monitoring sessions or participating remotely the
following information may prove useful.

For general remote participation including meetecho support see:

http://www.ietf.org/meeting/85/remote-participation.html

-Audio Streaming-

All 8 parallel tracks at the IETF 88 meeting will be broadcast starting
with the commencement of working group sessions on Monday, Nov 5 2012
at 0900 EST (UTC-5) and continue until the close of sessions on Friday,
Nov18th .

Because we have been asked several times in the past, note that if you
wish to use the rooms that are being recorded for impromptu meeting
during unscheduled sessions or lunch breaks that you can invite remote
participants to tune in to the appropriate stream. Recording cannot be
guaranteed for unscheduled sessions. Conversely, it should never be
assumed that recording or observation is not occurring on open
microphones, they are after all connected to the Internet.

The links for streaming sources and the schedule are best retrieved from
the IETF tools agenda, which as per standard operating procedure will be
located here:

http://tools.ietf.org/agenda/85/  


-Jabber/XMPP-

For information on IETF Jabber participation see:

http://www.ietf.org/jabber/index.html

or click on the Jabber links in the tools team agenda once you have a
properly configured jabber/xmpp messaging client.

-Webex-

Webex screen sharing participation is possible for a limited number of
sessions. Consult with your working-group chair or the secretariat for
more information.

-Ticketing-

For prompt access to the meeting trouble desk, the email address is:

m...@ietf.org

For streaming related issues please send email toietf-stream...@verilan.com  
with info including the current time and affected streaming channel.

Re: Recall petition for Mr. Marshall Eubanks

[Joel Jaeggli]

Mike,

A 3777 recall isn't dependent on the wishes of the IAOC...

Sent from my iPhone

On Nov 1, 2012, at 19:22, Michael StJohns  wrote:

> 

Re: I-D Action: draft-jaeggli-interim-observations-00.txt

[joel jaeggli]

On 10/26/12 9:00 AM, Spencer Dawkins wrote:
Thank you, Joel, for putting pen to paper (pixels to glass?) on this, 
and thank you, Jari, Randy, and Warren for sharing your thoughts.


As was pointed out, we've had conversations about LIMs previously. It 
might be worth asking Ray to provide a paragraph or two on history and 
the motivations when some of the previous LIMs were discussed.


My memory of the proposed 2009 Malta LIM (supplemented by Teh Google) 
was that the working groups planning to meet weren't just from one 
area of interest (something like four RAI groups, plus SOFTWIRES and 
BEHAVE). I don't know if that helps or hurts - at a minimum, 
RIPE/foonog may not be the draw for RAI that it was for the groups 
that met this time.
yeah I didn't have enough useful data on the proposed meeting in malta 
to really commit it to the initial draft.


for one I had the dates wrong in my notes.

FWIW, http://trac.tools.ietf.org/2009/jan-large-interim/ says 60 
potential attendees didn't qualify as a large interim :-)

that is useful.

Spencer

Re: IAOC Request for community feedback

[joel jaeggli]

On 10/23/12 4:25 PM, Bob Hinden wrote:

Responding to some of the discussion, I would like to raise a few points.

I don't see how the IAOC has bypassed any rules.  We are asking the community 
if it is OK to declare Marshall's position vacant.  Bypassing the rules would 
be true if the IAOC had gone ahead unilaterally and asked the NomCom to fill 
the reminder of Marshall's term.  The community consensus will determine the 
answer to the query.

We think the current procedures were not meant for this case and are not clear 
on the situation when to declare a position vacant.

BCP101 says:

   Any appointed IAOC member, including any appointed
   by the IAB, IESG, or ISOC Board of Trustees, may be recalled using
   the recall procedure defined in RFC 3777.

The use of "may" usually means do this unless there is good reason to do 
otherwise.  I think that is the case in this situation.

The IAOC has operational responsibilities.  Having one voting member not 
attending many meetings makes it harder obtaining a consensus.  Without a 
consensus the IAOC can not approve contracts, RFPs, etc.

Lastly, and I think most important, the IAOC proposed this approach because we 
think it would cause the least amount of embarrassment to Marshall.  Marshall 
has been active in the IETF for many years and has made many important 
contributions.  We proposed this course of action in respect to Marshall.  We 
think it's better to not subject him to the formal RFC3777 recall process.  
Having his position declared vacant is milder than having him be formally 
recalled.
The result of a 3777 process is theoretically not subject to appeal. 
which has a certainly finality on completion that I don't think this 
proposal has. I don't think the proposal is bad, but I don't think it is 
a generically appropriate approach.

Bob

Re: IAOC Request for community feedback

[joel jaeggli]

On 10/23/12 4:25 PM, Bob Hinden wrote:

Responding to some of the discussion, I would like to raise a few points.

I don't see how the IAOC has bypassed any rules.  We are asking the community 
if it is OK to declare Marshall's position vacant.  Bypassing the rules would 
be true if the IAOC had gone ahead unilaterally and asked the NomCom to fill 
the reminder of Marshall's term.  The community consensus will determine the 
answer to the query.

We think the current procedures were not meant for this case and are not clear 
on the situation when to declare a position vacant.

BCP101 says:

   Any appointed IAOC member, including any appointed
   by the IAB, IESG, or ISOC Board of Trustees, may be recalled using
   the recall procedure defined in RFC 3777.

The use of "may" usually means do this unless there is good reason to do 
otherwise.  I think that is the case in this situation.

The IAOC has operational responsibilities.  Having one voting member not 
attending many meetings makes it harder obtaining a consensus.  Without a 
consensus the IAOC can not approve contracts, RFPs, etc.

Lastly, and I think most important, the IAOC proposed this approach because we 
think it would cause the least amount of embarrassment to Marshall.  Marshall 
has been active in the IETF for many years and has made many important 
contributions.  We proposed this course of action in respect to Marshall.  We 
think it's better to not subject him to the formal RFC3777 recall process.  
Having his position declared vacant is milder than having him be formally 
recalled.

The result

Bob

Re: I-D Action: draft-jaeggli-interim-observations-00.txt

[joel jaeggli]

On 10/15/12 2:53 PM, Adrian Farrel wrote:

ok, i am lost.  the draft is only an outline and has zero content?  is
it a quiz?

Treat it like that and see if you can give Joel the right answers.
01 is available. I imagine the SIDR experience was a bit different, 
having been to another SIDR interim, I tried to call that out, but I 
wasn't in the room.


http://tools.ietf.org/html/draft-jaeggli-interim-observations-01

For me: Did it make any difference to you that it was a LIM rather than simply a
SIDR interim? Were logistics and resources worth the fee? Should we hold future
LIMs, or do the scheduling and other issues mean that normal interims are the
way forward?

cheers,
Adrian

Re: [IETF] Re: I-D Action: draft-jaeggli-interim-observations-00.txt

[joel jaeggli]

On 10/15/12 2:53 PM, Warren Kumari wrote:

On Oct 15, 2012, at 5:49 PM, Randy Bush  wrote:


ok, i am lost.  the draft is only an outline and has zero content?  is
it a quiz?

No, I believe that it is very subtle satire, reflecting Joel's view on the 
utility of the meeting :-P
or it's unsubtle and I just needed a structure and a 00 before the 
deadline, because the text that exists now isn't cooked enough yet. that 
may be an sube of the process but if there's an 01 before 1700 pacifc 
I'll post it.

imiho, the sidr meeting was useful and got work done which probably
would have taken a lot more time online and would have had the wonderful
email misunderstanding amplification.

+lots.

Sad as it is, getting folk together in a room helps focus the discussion and 
provides many fewer opportunities for misunderstanding…


randy


--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
---maf

Warren Kumari
war...@kumari.net

Re: In person vs remote participation to meetings

[joel jaeggli]

There are abundant examples of successful document editors and authors 
and the occasional area director working at a distance, some cases are 
harder than others.


The part that is hard to replace is, the opportunity for collegiality,  
for cross pollination, and many fine lunches  and dinners.


Working group participants are free to do what they want of course.

On 9/28/12 12:22 AM, Alessandro Vesely wrote:

Dear IETF,

I'm happy that Meetecho is gradually improving our remote
participation experience.  However, as a matter of fact, that is still
not quite the same thing as in person participation.

Question:  Consider a WG which is really in need of a face to face
meeting.  A very important participant, such as the editor of the main
WG document, however, would only participate remotely, because he is
an independent consultant and lacks specific funds.  Can the WG --in
such case-- set up some arrangements, e.g. take a collection up from
the other participants, or anything to a similar effect?  Are there
provisions or limitations?

IMHO, participation of individuals and small businesses is not less
important than that of newcomers from emerging and developing economies.

TIA for any hint.
Ale

 Original Message 
From: Steve Conte 
Date: Tue, 18 Sep 2012 13:34:02 -0700
To: Alessandro Vesely 
Cc: lead...@internetsociety.org, Public Software Mailing List

Subject: Re: The Internet Society Fellowship to the IETF

Dear Mr. Vesely,

Thank you for your email regarding the ISOC Fellowship to the IETF
Programme.  This specific programme is designed to increase IETF
participation from emerging and developing economies.

The IETF has tools in which to participate remotely.  We encourage
those who are not able to physically attend an IETF meeting to utilize
those tools so as to remain active in their participation.

Sincerely,

Steve Conte

On Sep 5, 2012, at 4:38 AM, Alessandro Vesely  wrote:


Dear ISOC,
one of the points for qualifying for the programme is:

   Originate from and reside in a emerging or developing economy,
   which traditionally have low rates of participation in the IETF.
  http://www.internetsociety.org/node/9476

I understand the intent and the limits of the programme, but I also
notice that the IETF "works for those who pay its members."[1]  That
fact may imply unwanted consequences, as far as free development (free
as in "free speech") of open standards is concerned.  Do you address
such topic on the ISOC web site?

For example, I know the case of a guy who is the editor of a standard
specification within a IETF working group, but doesn't participate to
IETF meetings because he has no funds for that.  He is an US citizen,
hence does not qualify for the programme because of the point quoted
above.  Indeed, that situation is quite frequent for small companies
and individuals.  Wouldn't it be possible to widen the participation,
for the sake of a democratic development of the Internet?

Thanks for your attention
Sincerely
AV

[1] JFC Morfin - Mon Sep 3 16:20:27 PDT 2012
[PubSoft] OpenStand and "modern" paradigms
https://elists.isoc.org/mailman/private/pubsoft/2012-September/002307.html

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[joel jaeggli]

On 9/18/12 11:46 PM, Joe Touch wrote:



On 9/16/2012 6:56 AM, Lawrence Conroy wrote:
...

It is VERY useful to be able to search through drafts to see how we
got here, AND to see things that were explored and abandoned.


Thieves find it very useful to have what they steal. That doesn't 
legitimize their theft.


Utility can determine whether it's worth the effort/expense to run a 
public archive, but your utility never undermines my rights as an author.

Non-lawyer here...

An authors rights are not entirely exclusive. e.g. 17 U.S.C 107 applies.

Joe

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Joel jaeggli]

On 9/3/12 18:29 , Sam Hartman wrote:
> I strongly urge  the IESG to be significantly more liberal in  the cases
> where an I-D will be removed from the archive.
> 
> I can think of a number of cases where I'd hope that the IESg would be
> cooperative:
> 
> 1) the IETF recieves a DMCA take-down notice or other instrument
> indicating that a third party believes an I-D infringes their copyright.
> Forcing such third parties to take the IETF to court does not seem to
> benefit the community.

non-laywer here,

The IETF is not an ISP and does not accordingly have safe harbor
privileges. I doubt very much  that it would be appropriate to dutifully
remove content merely on the basis of a dmca takedown request.

> 2) An author realizes that an I-D accidentally contains proprietary
> information, infringes someone else's copyright, failed to go through
> external release processes for the author/editor's organization, etc.
> Obviously factors like how long after the I-D is submitted might need to
> be considered.
> 
> 
> In conclusion, I believe there are a number of cases where the interests
> of the community are better served by being able to ask for removal from
> the archive. Being able to easily repair mistakes  is likely to
> facilitate  more free discussion and more speedy updating of I-Ds.
> Yes, I'm aware  that organizations other than the IETF mirror the i-ds
> and some of these organizations will be less sympathetic to these
> concerns.
> 

Re: IETF 92 in Dallas!

[joel jaeggli]

On 8/17/12 12:20 PM, Robert Raszuk wrote:


> Hotel contracts by their nature need to be negotiated under mutual
> NDA unless you want all the vendors in the region to mysteriously
> arrive at the same lower bound.

All hotel rates are wide open and published on IETF web page. It's an 
interesting NDA which permits open disclosure ;-)

The room rate is...
Besides hotel is least worry as we do know the IETF rates for the last 
few years and it is quite easy to check with any hotel if they are 
willing to meet those targets or not.


A week long meeting involving ~1200 people, dozens meeting rooms, plus 
ancillary meeting, receptions, takeover and operation of a network, av 
support, and catering is a rather different beast.



R.



On 8/17/12 12:05 PM, Robert Raszuk wrote:

Hi Bob,

Is there any way to broaden the scope of IAOC choice and provide the
candidate locations which would meet IETF criteria by any IETF member ?

For example once I know the criteria I could check around in Poland to
see if there is any place which would satisfy the future IETF venue.

I am sure friends from South America would be glad to conduct similar
local research in their neighborhood. So would others from other
continents.

Are the criteria for IETF meetings published or is this some sort of
top secret (for example how much the venue may cost) ?

Could we all contribute via a wiki page ? Could we make the IETF
choice of location an open process ?

Hotel contracts by their nature need to be negotiated under mutual NDA
unless you want all the vendors in the region to mysteriously arrive at
the same lower bound.

Re: IETF 92 in Dallas!

[joel jaeggli]

On 8/17/12 12:05 PM, Robert Raszuk wrote:

Hi Bob,

Is there any way to broaden the scope of IAOC choice and provide the 
candidate locations which would meet IETF criteria by any IETF member ?


For example once I know the criteria I could check around in Poland to 
see if there is any place which would satisfy the future IETF venue.


I am sure friends from South America would be glad to conduct similar 
local research in their neighborhood. So would others from other 
continents.


Are the criteria for IETF meetings published or is this some sort of 
top secret (for example how much the venue may cost) ?


Could we all contribute via a wiki page ? Could we make the IETF 
choice of location an open process ?
Hotel contracts by their nature need to be negotiated under mutual NDA  
unless you want all the vendors in the region to mysteriously arrive at 
the same lower bound.

Re: IETF 92 in Dallas!

[joel jaeggli]

On 8/15/12 9:49 PM, Alejandro Acosta wrote:

Hi All,
   In my humble opinion I totally agree with Arturo. So far I do know
several cities in Latin America and I believe Sao Paulo (Brazil) or
Cancun (Mexico) might be a good options. Of course there are many more
good cities, those ware the first two that came to my mind.
   I hope IETF 100 can be done over there.
Notably Sao Paulo gets a train line from GRU in time for the worldcup in 
theory, which would be a substantial accessibility improvement.


Some locations in the southern hemisphere where attendees hail from have 
even more painful routing than normal to GRU e.g. syd. The observation 
would be that it's a long-haul for all but a handful of attendees.

See you,

Alejandro,



On 8/15/12, Arturo Servin  wrote:

So "Americas" was actually "North America".

Well, it went the possibility to have one in central or south america, 
what
at shame. At least until IETF 98 in March 2017 no IETF down the south of Rio
Grande.

May I ask the IAOC, what are the impediments to have one IETF in Latin
America?

Regards,
as

On 15 Aug 2012, at 14:04, IETF Administrative Director wrote:


The IAOC is pleased to announce Dallas, TX, USA as the site for IETF 92
from March 22-27,
2015.  The IETF was last in Dallas for IETF 65 in 2006.  IETF 92 will be
at a different venue in
the Dallas Arts District.

Those who may be interested in hosting or sponsoring this or any future
meeting are invited to
contact Drew Dvorshak at dvors...@isoc.org.  See Host opportunities
below.

Ray Pelletier
IETF Administrative Director

IETF Meeting Schedule:

2012
IETF 85  Atlanta  4 - 9 November   Host: North American Cable Industry

2013
IETF 86  Orlando  10 - 15 March (Back-to-back with IEEE 802) Comcast &
NBC Universal
IETF 87  Berlin  28 July - 2 Aug  Host and Sponsors Sought
IETF 88  Vancouver  3 - 8 November  Host Sought

2014 - Hosts sought
IETF 89 London
IETF 90 Toronto
IETF 91   Honolulu  

2015 - Hosts sought
IETF 92 Dallas
IETF 93 Europe
IETF 94 Yokohama  WIDE