Re: [ietf-privacy] New Webiquette RFC

[Toerless Eckert]

Intersting historic insight, thanks, Ted.

So, in summary: "The Internet is for End-Users, but the IETF is not" ?  ;-)

Sounds like a bit as if the state of IETF wrt. to what you write contradicts 
RFC8890.

Shouldn't be too difficult to attempt reviving FYI in some gen area WG
if we believed we actually wanted to do something about rfc8890 that 
does not well fit other areas.

Cheers
Toerless

On Mon, Apr 18, 2022 at 09:53:37AM +0100, Ted Hardie wrote:
> Howdy,
> 
> 
> On Sun, Apr 17, 2022 at 9:18 PM  wrote:
> 
> > Thank you. I have oriented myself on this RFC:
> >
> >[RFC1855]  Hambridge, S., "Netiquette Guidelines", FYI 28, RFC 1855,
> >   DOI 10.17487/RFC1855, October 1995,
> >    
> > .
> >
> >
> > You will no doubt have noticed that this had both an RFC number and a
> designation as an FYI.  The FYI series has since been concluded:
> https://datatracker.ietf.org/doc/html/rfc6360 describes the action.  This
> is in part because that relevant part of the IETF (the User Services Area)
> had also wound down.
> 
> Given the decisions above, it would be difficult to identify a group within
> the IETF that could review an update to RFC 1855.
> 
> regards,
> 
> Ted Hardie
> 
> 
> 
> 
> > On 17.04.22 22:12, Stephen Farrell wrote:
> >
> > Perhaps if the author wishes the draft to proceed they will
> > be happy to self-identify, or perhaps not. I'd not worry
> > too much about the general problem 'till that's clear.
> >
> > The text of the draft itself seems innocuous enough. While
> > I'm not clear what useful purpose might be served by having
> > such text in an RFC, I'd be willing to be convinced but so
> > far remain to be convinced.
> >
> > Process-wise, I'd say unless this were modified to address
> > some IETF-specific issues (such as netiquette in developing
> > protocols) it'd likely be better targeted to the IAB or
> > ISE streams. (That's no reason to not discuss it here
> > though.)
> >
> > ___
> > ietf-privacy mailing list
> > ietf-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-privacy
> >

> ___
> ietf-privacy mailing list
> ietf-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-privacy


-- 
---
t...@cs.fau.de

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

Re: [ietf-privacy] New Webiquette RFC

[Toerless Eckert]

On Sun, Apr 17, 2022 at 12:48:45PM -0700, Bernard Aboba wrote:
> The questions you refer to are not new.  The same issues (IPR policy
> conformance and hidden agendas) have been raised with respect to the
> affiliations of ‘consultants’ who are hired by clients who wish to remain
> anonymous.  AFAICT, the IETF has never required that consultants divulge
> their clients, even to the nomcom.

Indeed. And there is a wide range how open or secret those consultants are
in the IETF about their sources of financing. And while this may be all quite
well-known to IETF old-timers, it would be nice to even just document these
insights to IETF newcomers. And RFC like the one suggested might be a good
start, although it would expand from "recommendations" to a broader "fyi".

> Anonymous participation takes this trend one step further.  The W3C does
> not allow anonymous participation due to IPR concerns, but their IPR policy
> is also significantly different, since W3C is membership-based (and not
> particularly friendly to ‘consultants’ or small businesses).

> We might decide that this anonymous participation is one step too far, but
> my take is that IETF crossed an important line long ago.

IMHO there is still a relevant difference between complete anonymity and some 
degree
of tracability/accountability through some form of "public" intermediary.

Cheers
Toerless

> On Sun, Apr 17, 2022 at 12:15 Christian Huitema  wrote:
> 
> > This submission raises an interesting question for the IETF: how to
> > treat anonymous (or pseudonymous) submissions?
> >
> > On one hand, there are lots of classic reasons for hiding behind a
> > pseudonym when participating in public discussions. On the other hand,
> > the IETF has to be protected against intellectual property issues and
> > against sabotage by external groups.
> >
> > Before submissions are accepted for publication, their authors have to
> > disclose whether they, or their employer, own intellectual property
> > rights on the technologies described in the draft. Failure to disclose
> > would influence the prosecution of intellectual property disputes that
> > might arise when third parties implement the technology. This provides
> > some degree of protection to implementers. But when the submission
> > cannot be traced to a specific company, these protections disappear, and
> > we might have a problem. So this is one source of tension between
> > standards and anonymity.
> >
> > The other source of tension is the risk of sabotage. Various groups have
> > tried to sabotage the standard process in the past, for example to delay
> > the deployment of encryption, or to introduce exploitable bugs in
> > security standards -- some of these tactics were exposed in the Snowden
> > revelations. Anonymous participation could allow these groups to perform
> > such sabotage in untraceable ways, which is obviously not desirable.
> >
> > I think this issue of anonymous participation is worth discussing.
> >
> > -- Christian Huitema
> >
> >
> > On 4/17/2022 11:35 AM, kate_9023+...@systemli.org wrote:
> > > Dear all,
> > >
> > > I'm quite new at creating RFCs. I have recently submitted a draft for
> > > a new webiquette and I am still searching a group which will take care
> > > of it. It would fit into privacy as this new webiquette is dealing
> > > with new internet technology such as deepfakes, sharing photos of 3rd
> > > parties and so on and also deleting old information on a regular basis
> > > good behavior. It's also quite short with only 9 pages and also covers
> > > cancel culture and mobbing. I think a document like this is needed and
> > > important. Anyone here who'd like to take care or helping me making an
> > > RFC out of it? Or guide me in the right direction?
> > >
> > > The draft can be found here:
> > >
> > https://www.ietf.org/archive/id/draft-rfcxml-general-the-new-webiquette-00.txt
> > >
> > > Best Regards,
> > >
> > > Kate
> > >
> > > ___
> > > ietf-privacy mailing list
> > > ietf-privacy@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ietf-privacy
> >
> > ___
> > ietf-privacy mailing list
> > ietf-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-privacy
> >

> ___
> ietf-privacy mailing list
> ietf-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-privacy


-- 
---
t...@cs.fau.de

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

Re: [ietf-privacy] [Tools-discuss] Upcoming end of support for the IETFers app

[Toerless Eckert]

Darn, messed up joke by typo, correct:

https://www.rfc-editor.org/rfc/rfc4041.txt
Section 2.2


On Fri, Aug 27, 2021 at 04:53:39PM +0200, Toerless Eckert wrote:
> To close on a lighter note: I was yesterday just randomnly stumbling across
> RFC4101 again and found particularily section 2.2 to be strikingly current.
> 
> Cheers
> Toerless
> 
> On Thu, Aug 26, 2021 at 09:16:28PM -0400, Tom Pusateri wrote:
> > FYI,
> > 
> > Given the change of position with Apple’s privacy directions, I no longer 
> > wish to continue development of the IETFers app on Apple platforms. After 
> > their strong privacy stance for many years, this feels like a betrayal to 
> > me.
> > 
> > I understand that some will think this is overblown or that maybe I want 
> > inappropriate material on my device. I can assure you that this is not the 
> > case. I detest the exploitation of minors and adults on the internet.
> > 
> > But a technology that is developed for service A will eventually be used 
> > for services B & C & D. Services B & C & D may not be made public but they 
> > will exist and Apple has shown their willingness to cross the line in 
> > public which makes me think they probably have already crossed the line in 
> > private too. But I don’t mean to drag anyone else into this part of the 
> > discussion or convince anyone about my beliefs. That is not the point of 
> > this note. Please don’t try to argue with me that what Apple is doing is ok.
> > 
> > The IETFers app will continue to work for future meetings as long as 
> > nothing in the API changes on which it depends. I have no control over that 
> > and I won’t go digging through the source code to try and figure out what 
> > busted.
> > 
> > I am aware of another timezone bug that surfaced during this last online 
> > meeting. I plan to fix this bug and make one last dot release before the 
> > next meeting.
> > 
> > I wanted to make this decision public so other plans can be made if needed. 
> > This is the real purpose of this note.
> > 
> > The next obvious question is will I be working on an Android version 
> > instead? I will answer this by saying the privacy problems on Android 
> > platforms are far worse.
> > 
> > For a stroll down memory lane, the IETFers app was first released 10 years 
> > ago in July, 2011. It was a fun project and I hope people benefited from it 
> > (and continue to do so). I’ll continue to hang out on this list and 
> > contribute where I can but just not on the Apple app.
> > 
> > Thanks,
> > Tom
> > 
> > 
> > 
> > ___
> > Tools-discuss mailing list - tools-disc...@ietf.org
> > This list is for discussion, not for action requests or bug reports.
> > * Report datatracker and mailarchive bugs to: datatracker-proj...@ietf.org
> > * Report tools.ietf.org bugs to: webmas...@tools.ietf.org
> > * Report all other bugs or issues to: ietf-act...@ietf.org
> > List info (including how to Unsubscribe): 
> > https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> Tools-discuss mailing list - tools-disc...@ietf.org
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: datatracker-proj...@ietf.org
> * Report tools.ietf.org bugs to: webmas...@tools.ietf.org
> * Report all other bugs or issues to: ietf-act...@ietf.org
> List info (including how to Unsubscribe): 
> https://www.ietf.org/mailman/listinfo/tools-discuss

-- 
---
t...@cs.fau.de

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

Re: [ietf-privacy] [Tools-discuss] Upcoming end of support for the IETFers app

[Toerless Eckert]

*,

Cc'ed to ietf-privacy@ietf.org in case there is interest in followup
discussions on the privacy issue raised. Surprisingly, that mailing
list is almosts dead, which strikes me as strange given IETFs strong
interest in privacy.

Given how i do not use iOS, i was more triggered by the remark about
android and be interested to learn more about that.

Otherwise, also a big thank from me knowing how many IETF'er use the app!

To close on a lighter note: I was yesterday just randomnly stumbling across
RFC4101 again and found particularily section 2.2 to be strikingly current.

Cheers
Toerless

On Thu, Aug 26, 2021 at 09:16:28PM -0400, Tom Pusateri wrote:
> FYI,
> 
> Given the change of position with Apple’s privacy directions, I no longer 
> wish to continue development of the IETFers app on Apple platforms. After 
> their strong privacy stance for many years, this feels like a betrayal to me.
> 
> I understand that some will think this is overblown or that maybe I want 
> inappropriate material on my device. I can assure you that this is not the 
> case. I detest the exploitation of minors and adults on the internet.
> 
> But a technology that is developed for service A will eventually be used for 
> services B & C & D. Services B & C & D may not be made public but they will 
> exist and Apple has shown their willingness to cross the line in public which 
> makes me think they probably have already crossed the line in private too. 
> But I don’t mean to drag anyone else into this part of the discussion or 
> convince anyone about my beliefs. That is not the point of this note. Please 
> don’t try to argue with me that what Apple is doing is ok.
> 
> The IETFers app will continue to work for future meetings as long as nothing 
> in the API changes on which it depends. I have no control over that and I 
> won’t go digging through the source code to try and figure out what busted.
> 
> I am aware of another timezone bug that surfaced during this last online 
> meeting. I plan to fix this bug and make one last dot release before the next 
> meeting.
> 
> I wanted to make this decision public so other plans can be made if needed. 
> This is the real purpose of this note.
> 
> The next obvious question is will I be working on an Android version instead? 
> I will answer this by saying the privacy problems on Android platforms are 
> far worse.
> 
> For a stroll down memory lane, the IETFers app was first released 10 years 
> ago in July, 2011. It was a fun project and I hope people benefited from it 
> (and continue to do so). I’ll continue to hang out on this list and 
> contribute where I can but just not on the Apple app.
> 
> Thanks,
> Tom
> 
> 
> 
> ___
> Tools-discuss mailing list - tools-disc...@ietf.org
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: datatracker-proj...@ietf.org
> * Report tools.ietf.org bugs to: webmas...@tools.ietf.org
> * Report all other bugs or issues to: ietf-act...@ietf.org
> List info (including how to Unsubscribe): 
> https://www.ietf.org/mailman/listinfo/tools-discuss

-- 
---
t...@cs.fau.de

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

Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats

[Toerless Eckert]

Jari, *:

Disclaimer: see signature (i do not know the details of this specific case).

To me the problem seems to be going back to the means the IETF has for 
providing recognition
to participants contributing by review/feedback. As long as recognition for 
that contribution
is primarily left to the disgression of the listed draft authors, it will 
negatively impact
the amount of especially critical feedback/review the IETF will see. Unless a 
contributor has
a specific business reason to reject or help to improve a drafts, its most 
likely not worth
their time to fight / improve documents without better means of recognition 
than how its
defined today. Especially if their job role lives off showing recognition for 
their contribution
to their employer/sponsor.

As much as i hate overboarding processes, an explicit review tool tracking 
feedback
and approval/disapproval of documents may be able to help here. Especially 
given how
there is already tooling to show some form of IETF score based on explicit
authorship. You know who's tool i am talking about ;-)

Not claiming i am persuaded that the problem is significant enough to invest 
into an
explicit review tool, just saying its more than just difference of opinions or 
rough
consensus as you seem to claim (if i undestood you correctly).

Cheers
Toerless

On Wed, Jul 03, 2013 at 07:19:20AM +0200, Jari Arkko wrote:
 
  i have never considered writng one.  sour grapes make bad wine.
 
 Errors do happen, for everyone and for all organisations. We do not treat 
 appeals as sour grapes at the IESG, IAB or other places that receive them. We 
 consider them an opportunity to review whether something was missed. At the 
 same time, we do not intend to give special treatment to an argument just 
 because it is labeled as an appeal. Sometimes legitimate differences of 
 opinion are just that, and consensus was rough.
 
 Jari
 

-- 
---
Toerless Eckert, eck...@cisco.com
It's much easier to have an opinion if you do not understand the problem.

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

A question because my institutional memory does reach as far back:
How much was Europe represented over the decades in IETF leadership ? 

Right now for example IESG seems to have maybe at least 5
europeans (don't really know how to figure out location for all of them,
those where just the easy ones for me).   But i would expect that this
was by far not the case going back in time.

Nobody cares about diversity for europeans in this round of the 
discussion, but i wonder if this was equally true in the past.

Maybe this evolution would be a good example to folks without that long
reaching institutional memory to show how the IETF leadership
does pretty well  reflect the evolution of the industry. If the
industry will become more diverse, IETF will reflect this equally.
If on the other hand we try to achieve greater diversity than the
industry, then we have a real challenge on our hand. 

The concentration to fewer and larger companies in todays vs. past
leadership was mentioned in before as bad. I think its exactly
for the same reason.


On Sat, Apr 13, 2013 at 12:32:18PM +, Ted Lemon wrote:
 On Apr 13, 2013, at 6:44 AM, Arturo Servin arturo.ser...@gmail.com wrote:
  Me too, but when you have a diverse pool of people
  who feel strongly about open standards, rough consensus and running code
  and you choose only one category of the group, then we need to think
  about how we end up in that situation.
 
 Yes.   I'm not arguing that there is not a problem: I'm arguing that if the 
 problem were solved, it would not make me feel less well represented.   The 
 point is definitely not to turn that around and suggest to those who 
 currently do not feel well-represented that they should not?the situations 
 aren't analogous.
 

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

On Thu, Apr 11, 2013 at 04:40:57PM -0800, Melinda Shore wrote:
 My own feeling is that if we were to find that the
 numbers supported the notion that there's bias
 present in the system we probably couldn't do anything
 about it without tearing the organization apart, so,
 we live with bias, and trying to identify whether or
 not there's bias in the nomcom process would be something
 along the general lines of opening the gates of hell
 and we'd probably be better off not knowing for sure.

I still think that the IETF community at large has no intentional
diversity bias, so the process of discussing and analyzing
diversity in the context of leadership is to help better describe 
diversity induced job qualifications as well as uncovering any
potential unconscious bias to help overcoming it.

 But I digress.  It seems to me that it might be more
 useful to identify what it is you're trying to find out,
 first, and in this case I'm really not sure why Ray asked
 that particular question.

Right. Being nomcom, i am of course interested to see what
answers we can get to help improve analyzing our situation, so
whether or not we can create good analysis vs. divesity fators,
I think the questions i proposed just by themselves would give
a good insight about awareness in the community about the role
of leadership, and maybe give us some more insight into the possible
pool.

Cheers
Toerless

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

Given how in my understanding, a key concern is really a perceived or real
diversity bias in IETF leadership, if you do add questions about diversity, 
please also add
the following questions. In fact, i think it would help the nomcom process to 
ask
these questions whether or not you also ask about diversity.

[Y/N] I understand the job requirements for an IESG member
[Y/N] I understand the job requirements for an IAB member
[Y/N] I consider myself qualified for an IESG/IAB position and I am willing to 
serve.
[XX]  How many hours per week does an IESG member need to spend on average on 
the job ?

Explanation:

The first three question could allow based on self assessment to evaluate 
whether
IETF leadership is biased based on diversity stats or not. Without these 
questions
i am sure somebody would come up with stats that simply map diversity of 
existing
leadership to the diversity stats of the community responding during 
registration.
Of course, self-assessment is not ideal, but much better than nothing.

Question number 4 is just a simple checksum question to assess if there was a 
mistake
in answering the prior three questions.

In addion of course  the generic questions i miss on almost every questionaire:

[ ] How much did you like the questions we asked (1=useless ... 5=perfect)

Please tell us what questions we should have asked:
[ at least 4 lines by 80 characters space for replies ]

Thanks
Toerless

On Thu, Apr 11, 2013 at 11:17:14AM -0400, Ray Pelletier wrote:
 And please direct your comments to i...@ietf.org
 
 Thanks
 
 Ray
 
 On Apr 11, 2013, at 11:11 AM, Ray Pelletier wrote:
 
  All
  
  The IETF is concerned about diversity.  As good engineers, we would like
  to attempt to measure diversity while working on addressing and increasing
  it.  To that end, we are considering adding some possibly sensitive
  questions to the registration process, for example, gender.  Of course,
  they need not be answered and would be clearly labeled as optional.
  
  The IAOC would like to hear from the community on this proposal.  It plans 
  to 
  make a decision on its 18 April call in order to make the changes in time 
  for the 
  Berlin registration and will consider all input received by 17 April.  
  
  Thanks for your feedback.
  
  Ray
  IAD
  
 

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

When adding diversity questions to the registration form, i think there should
be a very crisp description, whom exactly this information is made available to,
and how it is meant to be used.

If the total stats for example are simply made available publically and there
are not also other stats like the ones i asked for, then the effort will just
reinforce bogus statistical claims.

On Thu, Apr 11, 2013 at 01:33:21PM -0300, Arturo Servin wrote:
 
 On 4/11/13 1:00 PM, Toerless Eckert wrote:
  if you do add questions about diversity, please also add
  the following questions.
 
   Please no.
 
   This is about the registration form, not a survey.
 
 .as

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

On Thu, Apr 11, 2013 at 12:58:07PM -0400, Thomas D. Nadeau wrote:
 questions must be optional to answer too.

Definitely.

 Tom 
 
 
 On Apr 11, 2013, at 12:54 PM, Toerless Eckert eck...@cisco.com wrote:
 
  When adding diversity questions to the registration form, i think there 
  should
  be a very crisp description, whom exactly this information is made 
  available to,
  and how it is meant to be used.
  
  If the total stats for example are simply made available publically and 
  there
  are not also other stats like the ones i asked for, then the effort will 
  just
  reinforce bogus statistical claims.
  
  On Thu, Apr 11, 2013 at 01:33:21PM -0300, Arturo Servin wrote:
  
  On 4/11/13 1:00 PM, Toerless Eckert wrote:
  if you do add questions about diversity, please also add
  the following questions.
  
 Please no.
  
 This is about the registration form, not a survey.
  
  .as
  
  -- 
  ---
  Toerless Eckert, eck...@cisco.com
  Cisco NSSTG Systems  Technology Architecture
  SDN: Let me play with the network, mommy!
  
  

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

That's the tail wagging the dog. 

On Thu, Apr 11, 2013 at 02:19:55PM -0300, Arturo Servin wrote:
 
   Yes, but then you would end up with a large registration form that
 people may decide not to complete at all.
 
   
 .as
 
 On 4/11/13 1:58 PM, Thomas D. Nadeau wrote:
  questions must be optional to answer too.
  
  Tom 
  
  
  On Apr 11, 2013, at 12:54 PM, Toerless Eckert eck...@cisco.com wrote:
  
  When adding diversity questions to the registration form, i think there 
  should
  be a very crisp description, whom exactly this information is made 
  available to,
  and how it is meant to be used.
 
  If the total stats for example are simply made available publically and 
  there
  are not also other stats like the ones i asked for, then the effort will 
  just
  reinforce bogus statistical claims.
 
  On Thu, Apr 11, 2013 at 01:33:21PM -0300, Arturo Servin wrote:
 
  On 4/11/13 1:00 PM, Toerless Eckert wrote:
  if you do add questions about diversity, please also add
  the following questions.
 
 Please no.
 
 This is about the registration form, not a survey.
 
  .as
 
  -- 
  ---
  Toerless Eckert, eck...@cisco.com
  Cisco NSSTG Systems  Technology Architecture
  SDN: Let me play with the network, mommy!
 
 

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: IETF Diversity Question on Berlin Registration?

[Toerless Eckert]

Suggesting that simply diversity stats across all IETF participants can help
to deduce anything about leadership diversity bias is ignoring qualification
and availability of candidates. Thats why i proposed the questions i would like 
to see
in a questionaire.


On Thu, Apr 11, 2013 at 09:14:59PM +, Ted Lemon wrote:
 On Apr 11, 2013, at 5:10 PM, David Meyer d...@1-4-5.net
  Yes, but that is a different question. --dmm 
 
 
 IOW, you are suggesting that the percentages among non-attending participants 
 may be substantially different than the percentages among attending 
 participants?   That's a point worth studying, but wouldn't likely be 
 addressed by the proposed survey, unless some way were added to include 
 non-attending participants.
 

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: Diversity of IETF Leadership

[Toerless Eckert]

On Wed, Mar 20, 2013 at 03:59:34PM -0400, Jeffrey Haas wrote:
 On Wed, Mar 20, 2013 at 03:13:01PM -0400, Sam Hartman wrote:
  Part of what I meant when I signed the diversity letter was to state a 
  belief
  that within a pool of qualified candidates, I believe diversity is
  important enough that it is valuable to select for diversity even if
  this does not maximize the skills that you enumerated (tech skill, admin
  skill, works with others and something else).
 
 Maximize overstates my position.  My belief is once the base requirements
 are met that diversity is an appropriate tie-breaker.  Maximizing the four I
 mentioned is different.

I think that diversity is already taken into account
much more than just as a tie-breaker. Nomcon does
look at a lot of the factors influenced by the
candidates background / diversity stats already as
actual job qualifications: Knowlege/presence of
geographic regions, collaborative influencing leadership
stle, ability to engage with other cultures, etc. pp.

Cheers
Toerless

Re: Thoughts from a past experimental Nomcom selection for TSV Area Director

[Toerless Eckert]

Thanks, David. Good insight for the community.

On Tue, Mar 12, 2013 at 04:41:43PM -0400, David Harrington wrote:
 Hi,
 
 Many suggestions have been made about ways to resolve the issue of finding
 suitable candidates for TSV Area Director, or adjusting the job to fit
 available candidates.
 
 In 2010, I started as TSV AD, after the Nomcom had serious trouble filling
 the TSV AD spot. I was encouraged to put my name in as a candidate since I
 had solid IETF experience, even though I had no experience with the TSV
 area. Interviewing for the position really confirmed for me how little I
 knew about transport, so I was very surprised when I was nominated. 
 
 After two years in that specific role, I have some insights I would like to
 impart to the Nomcom and the community, and especially to any candidates for
 the role who have never served on IESG. I'll repeat some of what has already
 been suggested, but I'll try to put these things together to help explain
 some contextual relationships that exist.
 
 I. the overall workload
 
 I found IESG/AD work to be a fulltime position, as in 100%. My first year, I
 worked anywhere from 60 to 90 hours per week. Of course, I had a lot of
 remedial learning to do; honestly, technical on-the-job training for a whole
 area while working to perform your IESG review work and other AD tasks is a
 tremendous burden. You won't do this in 50% of a normal work week. My second
 year, I cut back the number of hours to 50-60 hours a week and took some
 vacation time, so I could have a life beyond IESG, and the quality of my
 work and my queue management suffered seriously as a result. YMMV. My main
 concern is that a candidate with no area background can fall behind quickly,
 and possibly never catch up fully within a two-year term.
 
 The workload has two parts - the IESG/steering/approval part, and the area
 directing/managing part. I learned over time to split this generally by week
 - one week IESG, the next week AD. Otherwise it becomes hard to prioritize
 because it is very difficult to prioritize both (time-competing) parts
 simultaneously, without favoring one or the other. The job requires you to
 do both.
 
 II. workload - IESG 
 
 IESG work requires review of about 15 documents every two weeks; those
 documents come from anywhere in the IETF. Many of those documents require
 the reviewer to understand the normative references upon which the document
 is built. Internet standardization is now quite mature, and much of the new
 standards work is dependent on older standards. I came from the SEC area and
 the NM side of the OPS area, and those can be somewhat isolated from TSV,
 INT, RAI, and routing. If your background has been limited to working in one
 or two areas, you may need to learn a LOT about the technical developments
 and the existing standards in the other areas. If you have been an active
 reviewer in one or more directorates, and/or have previous IESG experience,
 that should help a lot, but I still found it a challenge even after
 experience in multiple directorates; when you do a security review of a
 congestion control document, you look for security issues, not congestion
 control issues.
 
 You'll need enough understanding of the TSV issues to be able to spot bad
 transport-related decisions in documents coming from elsewhere in the IETF.
 You (and your co-AD) are effectively the reviewer of last resort for TSV
 issues. If you don't understand control loops, congestion control
 techniques, etc., you will NEED to rely on your directorate for assistance
 in this role.
 
 If you pride yourself on the thoroughness of your reviews, as I did, get
 over it; you won't have time for thorough reviews.
 
 Some have commented on the extra stuff related to IESG work, such as
 cross-SDO coordination, process tweaking, and so on. These definitely take
 time, and they are important because that is part of the job. But other IESG
 members can handle the bulk of this extra work while you're still learning
 the area.
 
 III. workload - AD
 
 The AD for an area becomes the spokesman/shepherd for all documents coming
 from their area. When you bring it to the IESG, you will be asked about the
 quality of the document, the technical content, whether certain questions
 were considered, what impact this might have to existing networks, how well
 the document follows established guidelines for security, management,
 operations, IANA assignments, XML usage, and so on. You should know those
 guidelines exist and have already asked most of the relevant questions and
 had them addressed before you put a document on the telechat agenda. You can
 ask various directorates for help. Not knowing the technology will require
 you to go ask your experts and try again, possibly repeatedly (you don't get
 to bring experts with you to IESG telechats); this can seriously slow the
 advancement of a document, and the document should be in your high-priority
 queue until it passes.
 
 Sometimes 

Re: The desires of the IETF community

[Toerless Eckert]

On Fri, Mar 08, 2013 at 07:01:00AM -0800, S Moonesamy wrote:
 Hi Tom,
 At 06:48 08-03-2013, t.p. wrote:
 How (apart from posting to this list)?
 
 Talk to the individuals who are part of NomCom 2012.  It's easier to 
 discuss face to face.  There is also an email address ( 
 nomcom-ch...@ietf.org ) to reach NomCom.  I have no doubt that NomCom 
 2012 would appreciate any constructive input.

Mailing list to reach NomCom 2012 is nomco...@ietf.org.
nomcom-ch...@ietf.org reaches only (surprise) the NomCom chair (Matt).

No idea why its not explicitly mentionon www.ietf.org/nomcom,
i have seen it mentioned multiple times on these mailing lists.

Cheers
Toerless

Re: Nomcom is responsible for IESG qualifications

[Toerless Eckert]

On Fri, Mar 08, 2013 at 07:10:49PM -0800, Dave Crocker wrote:
 From one Nomcom to the next, the sense of authority and obligation for 
 a Nomcom should be consistent.  What a Nomcom does with that will (and 
 probably should) vary enormously, of course, but they should all work 
 from a common understanding of their charter.

I was told it was intentional not to maintain institutional memory
across consecutive nomcoms. Practically speaking there is of course
some institutional memory through chair, prior chair and advisors.

Creating more institutional memory through documentation would of
course provide a better community insight into the process evolution.

Past NomCom reports are a way to provide sugestions for following NomComs,
but so far they look to me mostly like starting off at 0, and not
trying to incrementally improve. Which means that the work of each
consecutive nomcom to take them into account would increase.

And a 3777bis of course would provide direct community input into the
process evolution.

Cheers
Toerless

  Also, while the nomcom decides the requirements for
 specific positions,
 
 Again:  that's nice, simple, clear language, but it does not reflect 
 what some Nomcoms have believed was their charter.
 
 We should revise the language to make authorities and responsibilities 
 far more clear.
 
 As I explained in an earlier posting, I see a reasonable reading of the 
 current text as /not/ assigning the authority to the Nomcom.  It's fine 
 that other read it differently, but that's not the point.
 
 It should require really creative mis-reading to get an interpretation 
 that differs from everyone else.
 
 d/
 -- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: Appointment of a Transport Area Director

[Toerless Eckert]

 PS.: I just spent a day at CeBIT.  One guy there reported to that he has seen 
 35000 active devices on his WiFi snooper.
 I'm not quite sure what that means, but he seemed to be implying at a 
 specific point in time.
 Go congestion control that.  And then prove that your solution works.

Bear proof ?

802.11 CSMA/CA does make sure that every participants gets so little bandwidth 
in this situation that L3 congestion control is not the issue.

(I don't have to proof that i am faster than the bear, just that there is 
somebody slower)

 Somehow, we still seem to be deploying WiFi, nonetheless, and some even 
 consider WiFi a success.

Its being used and continues to make money, and there is nothing else that 
works better
because otherwise that would have been successfull.

 Would your hypothetical AD waiting for sufficient work was done have 
 approved WiFi?  In 1998?

Do you think with your type of AD requirements we would have better WiFi today ?

Seriously, i think you're overthinking it. There are expert group participants, 
there are WG-Chairs
and there are ADs. I think this discussion circulates way too much around 
thinking that we must
shift technical expertise two layers up the management chain. Its a nice 
concept, it gives a warm
and fuzzy community feeling, we had the luxury enjoying it in many areas in the 
past, but it
does not scale nor is there IMHO any good proof that it works better than what 
i described
and what commercial companies exercise. In addition i would contend it tends to 
burn great
technical experts in the AD role. Yes, i can see how its cool to be burned fast 
with all the
stuff you get to see and judge in an AD role - for a while.

Cheers
Toerless

Re: Appointment of a Transport Area Director

[Toerless Eckert]

Btw: RFC3777 3.7.2 seems to define only the criteria to be applied by 
NomCom, not for the confirming body. 

On Thu, Mar 07, 2013 at 09:21:41AM -0500, Margaret Wasserman wrote:
 
 Hi Russ,
 
 On Mar 5, 2013, at 11:18 AM, Russ Housley hous...@vigilsec.com wrote:
  The rest of your question ought to be discussed at the TSVAREA meeting in 
  Orlando.
 
 I have looked at the agenda of the TSV Area Open Meeting (on Wednesday from 
 9:00am to 11:30am), and it includes the following item:
 
 - Open Mic about Area Expectations for the TSV ADs -- 60 minutes
 The questions we will ask the community:
   - what is the existing description we gave to NomCom.
   - does the community agree with it?
   - is it reasonable, or are we asking too much?
 
 By description we gave to the NomCom do you mean the IESG's list of desired 
 criteria?  Is the NomCom also going to report on the criteria that they came 
 up with, after considering the IESG's input and whatever input they received 
 from the community?
 
 I am a little bit confused about the purpose of this meeting.  Is it for the 
 IESG to get feedback on their desired criteria, so that those criteria could 
 potentially be updated for future years?  Or is it for the nomcom to get 
 further information from the community in order to determine the actual 
 criteria the nomcom will use (based on input from both the IESG and the 
 community) to fill the open TSV AD position this year?
 
 I would like to know the purpose of the meeting, because I believe it would 
 be appropriate for me to participate in a discussion of the former topic, but 
 not the latter.
 
 Margaret
 
 
 
 
 

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: Appointment of a Transport Area Director

[Toerless Eckert]

:gs/nomcom/nomcom process/

On Thu, Mar 07, 2013 at 10:40:32AM -0800, David Kessens wrote:
 
 Sam,
 
 On Thu, Mar 07, 2013 at 01:32:59PM -0500, Sam Hartman wrote:
  
  I don't think there is hair splitting going on here; I think the issues
  that are being raised are quite real and important.  It's not the IESG's
  fault if the nomcom does x.  It is the IESG's fault if the IESG takes on
  tasks delegated to the nomcom in RFC 3777.  As you are aware, I have
  taken concerns I believe are best handled by the IAB and nomcom to the
  IAB and nomcom.
 
 The nomcom makes the appointments.
 There is nothing the IESG can take away
 from that. It is the nomcom that interprets the requirements from the
 IESG. There is nothing the IESG can do about that. If you are unhappy how
 the nomcom does the interpretation, contact the nomcom. 
 
 David Kessens
 ---

Re: congestion control? - (was Re: Appointment of a Transport Area Director)

[Toerless Eckert]

Martin,

An article like this is the best reason why we should never finally resolve the
buffer bloat issue: Doing that would take away the opportunity for
generations of researcher to over and over regurgitate the same proposed
improvements and gain PhDs in the process.

I mean the Internet wold be like math without fermats last theorem.
Have you seen how disenfranchised mathematicians are now ? Its worse than the 
mood at
Kennedy Space center without a shuttle program (to bring the discussion back to
relevant aspects of IETF Orlando).

Sorry. could'nt resist.

I was actually happy about using some of those UDP based flow control reliable
transports in past years when i couldn't figure out how to fix the TCP stack of
my OSs. Alas, the beginning of the end of TCP is near now anyhow with RTCweb 
deciding
to use browser/user-level based SCTP over UDP stacks instead of OS-level TCP. 

On Tue, Mar 05, 2013 at 01:41:35AM +0100, Martin Rex wrote:
 Bob Braden wrote:
  On 3/4/2013 10:20 AM, Roger Jørgensen wrote:
   I'll ask a rather basic question and hope someone will answer in an 
   educational way - Why is congestion control so important? And where 
   does it apply? ... :-) 
  
  Ouch. Because without it (as we learned the hard way in the late 1980s) \
  the Internet may collapse and provide essentially no service.
  
 It is PR like this one:
 
   http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html
 
 That gets me worried about folks might try to fix the internet
 mostly due to the fact that they really haven't understood what
 is already there any why.
 
 -Martin

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: congestion control? - (was Re: Appointment of a Transport Area Director)

[Toerless Eckert]

On Tue, Mar 05, 2013 at 07:52:56AM +, Eggert, Lars wrote:
 On Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca wrote:
  The Transport Area has all of the groups that deal with transport
  protocols that need to do congestion control.   Further, the (current)
  split of work means that all of the groups that need congestion
  oversight would be cared for by the position that is currently becoming
  empty as Wes leaves.
 
 Also, other areas frequently build protocols that need review from a 
 congestion control perspective (do they back of under loss, can they even 
 detect loss, etc.)
 
 Inside the area, there is typically enough CC clue applied by the TSV 
 community as a whole. It's outside the area where the TSV AD as a person gets 
 involved a lot.
 
 Lars

Sure, but that could equally well be seen as a problem of the way how the
IESG chooses to perform its business. There are enough experts that
could consult whether its in role of directorates or else. They may just
not want to take on an AD role.

And there are a lot more TSV friction points with whats going on in the IETF
than just CC.

Re: Appointment of a Transport Area Director

[Toerless Eckert]

+1 +1 +1

On Sun, Mar 03, 2013 at 08:24:58PM +, Scott Brim wrote:
 On 03/03/13 15:14, Michael Richardson mcr+i...@sandelman.ca allegedly
 wrote:
 To be considered qualified the candidate needed to:
   a) have demonstrated subject matter expertise (congestion in this case)
 
 (I just want to nit on this: I hope people don't think TSV is just about
 congestion.)

Re: Appointment of a Transport Area Director

[Toerless Eckert]

On Sun, Mar 03, 2013 at 03:55:39PM +, Eggert, Lars wrote:
 only if the Y directorate reviews all IDs going through the IESG. Which in 
 itself is a scaling issue. It may work for some topics, but things will fall 
 through the cracks for various reasons. 
 
 IMO congestion control is important and fundamental enough that the IESG 
 itself needs to have the knowledge. YEs, I'm biased.

Searching for Congestion Control Expert on google shows no real matches at 
all before
this discussion thread. I could find Unicorn expert though. I wonder if those 
would make a good TSV AD.

Would you mind to describe how to evaluate someone to meet the bar to be CCE in 
your opinion ? 
I ask because starting to populate this new term into googles cache doesn't 
mean its clear
whether the community would even have a common idea of what it would mean. 
Independent of
whether the community thinks its a good bar for TSV-AD in the first place.

Re: Appointment of a Transport Area Director

[Toerless Eckert]

Really ? You don't think a good AD should primarily look for factual evidence
(lab, simulation, interop, ..) results produced by others to judge whether
sufficient work was done to proof that the known entry critera are met 
(like no congestion cllapse) - instead of trying to judge those solely
by himself/herself ? 

On Tue, Mar 05, 2013 at 10:12:43PM +0100, Carsten Bormann wrote:
 On Mar 5, 2013, at 18:58, Bob Braden bra...@isi.edu wrote:
 
  Which is why we learned 30 years ago that building a transport protocol at 
  the application layer is generally a Bad Idea. Why do the same bad ideas 
  keep being reinvented?
 
 Because we don't have a good selection of transport protocols at the 
 transport layer.
 
 I'm chairing one of the WGs with a UDP-based application protocol.
 TCP's congestion control, even if we could use TCP, wouldn't do much for us.
 
 Now here is my point:
 I need TSV ADs that are strong on the technical side.
 A weak TSV AD might be
 -- too cautious, listening to all kinds of Cassandras that haven't bothered 
 to look at the actual protocol, slowing us down unneededly, or
 -- too bold, allowing us to deploy a protocol that causes a congestion 
 collapse that can only be alleviated by physically chiseling nodes out of 
 walls.
 
 Clearly, I want neither of these to happen.
 (Now, we have received pretty good transport input in 2012, but the IESG will 
 look at this in 2013, and that's where a highly educated decision has to be 
 made.)
 
 Grüße, Carsten
 

-- 
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems  Technology Architecture
SDN: Let me play with the network, mommy!

Re: IPv6 not operational (was Re: Consensus Call: draft-weil-shared-transition-space-request)

[Toerless Eckert]

Not sure why rfc1981 PMTUD was never fixed. I've repeatedly tried to
suggest to just forget about PMTUD for IP multicast, and i have never
come across a good use case to justify MTU  1280 for IP multicast
across the Internet.

We did manage to get section 11.1 into rfc 3542 though. It's a little
bit long due to committee design, but i was hoping it was sufficient to avoid
the problem by default. It recommends sender side MIN_MTU fragmentation
by default for IP multicast sent into IPv6 sockets.

If folks see IPv6 multicast  1280 as a
real problem in deployments, pleae let me know. It would either indicate
socket stacks not observing rfc3542 or intentionally badly written
applications.

Cheers
Toerless

 Daryl Tanner wrote:
 
  The IPv6 chickens and eggs discussion could (and probably will) go on
  forever:
 
  service provider -  no content
 
  IPv6 is the right answer,
 
 Wrong.
 
 IPv6 is not operational, which is partly why most service
 providers refuse it.
 
 For example, to purposelessly enable multicast PMTUD, RFC2463
 (ICMPv6) mandates routers generate ICMPv6 packet too big
 against multicast packets, which causes ICMPv6 packet
 implosions, which is not operational.
 
 For further details, see my presentation at the last APNIC:
 
   How Path MTU Discovery Doesn't work
   http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf
 
   Masataka Ohta
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf