Re: Consensus on the responsibility for qualifications? (Was: Re: Nomcom is responsible for IESG qualifications)

[John Leslie]

Dave Crocker  wrote:
>... 
> On 3/13/2013 9:07 PM, John Leslie wrote:
>> I see several problems with this text:
>>
>> 1) It wanders from the current clear distinction between "desired
>> expertise", determined by the body where the nominee will serve,
>> and "IETF community's consensus of the qualifications required",
>> determined by waving the right magic wand. ;^)
> 
> Harumph!  It doesn't wander.  It moves with dedicated purpose...

   ;^)

> What text you are proposing as an alternative?

   I'll come back to that...

>>> it then advises each confirming body of its respective candidates;
>>> the nominating committee shall provide supporting materials that
>>> cover its selections, including the final version of requirements
>>> that the nominating committee used when making its selections;
>>
>> strikes me as too little, too late: the confirming body should learn
>> of any relaxing (least of all changes!) to the "desired expertise"
> 
> see above.

   There's a lot of "above". Which in particular?
 
>>> these requirements shall be made public after nominees are
>>> confirmed.
>>
>> This seems too vague. I'd suggest we consider listing actual
>> "requirements" in a formal report posted to .
> 
> Again, there is a range range of important procedural detail that
> the existing does not provide.  I'm in the camp that thinks that's 
> appropriate.  We haven't had a problem with the lack of formal 
> specification for those details.  Let's not fix something that's
> been working well.

   But it hasn't been working well! You have said yourself that some
prior NomComs have felt prevented from changing anything of the
"desired expertise".

> Revised draft text:
> 
> 2. The nominating committee determines the criteria for the
>job, synthesizing the desires expressed by the IAB, IESG or
   ^^^
should be "desired expertise"

>IAOC (as appropriate), desires express by the community, and
^^^
should be "qualifications required" 

>the nominating committee's own assessment; it informs the
>community and candidates of these determined criteria;

   "Informing the community" is technically sufficient; but I still
believe that the NomCom being chosen randomly is unlikely to have
much expertise in judging community consensus: the confirming bodies
are much more likely to have that expertise, and the confirming
bodies may disagree with the NomCom's judgment of these criteria.
Some formal consultation with the confirming bodies before publishing
the criteria to the full community is likely to avoid a rash of
troubles...

   Regardless of the text here, somebody who disagrees with the
NomCom's judgment of consensus on these criteria will find a way
to appeal. :^(

>it advises each confirming body of its respective candidates;
>the nominating committee shall provide the confirming body
>with supporting materials that cover its selections,
>including the final version of criteria that the nominating
>committee used when making its selections.

   There is a whole lot which needs to happen after publication of
criteria and before informing confirming bodies of nominations.
At the very least, there should be a paragraph break here...

--
John Leslie > 

Re: [TLS] Last Call: (The TLS Multiple Certificate Status Request Extension) to Proposed Standard

[Alexey Melnikov]

On 15 Mar 2013, at 13:35, The IESG  wrote:

> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'The TLS Multiple Certificate Status Request Extension'
>   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-03-29. 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 defines the Transport Layer Security (TLS) Certificate
>   Status Version 2 Extension to allow clients to specify and support
>   multiple certificate status methods.  Also defined is a new method
>   based on the Online Certificate Status Protocol (OCSP) that servers
>   can use to provide status information not just about the server's own
>   certificate, but also the status of intermediate certificates in the
>   chain.

I read the document. I think it adds important functionality. It is clearly 
written, so I support its publication.

Re: [core] Last Call: (Constrained Application Protocol (CoAP)) to Proposed Standard

[Shoichi Sakane]

4.6.  Message Size

  A CoAP message, appropriately encapsulated, SHOULD fit within a
  single IP packet (i.e., avoid IP fragmentation) and (by fitting into
  one UDP payload) obviously MUST fit within a single IP datagram.  If
  the Path MTU is not known for a destination, an IP MTU of 1280 bytes
  SHOULD be assumed; if nothing is known about the size of the headers,
  good upper bounds are 1152 bytes for the message size and 1024 bytes
  for the payload size.



 this may motivate
 implementations to be frugal in their packet sizes and to move to
 block-wise transfers [I-D.ietf-core-block] when approaching three-
 digit message sizes.


This draft says a coap message must fit within a single IP datagram.
on the other hand, however, to avoid fragmentation, this draft may
suggest to use the block-wise transfer, which is defined by another
draft.

If the payload size is more than the minimum MTU, the block-wise transfer
works.  If the total length of the options is bigger, the mechanism
doesn't work.  And, the length of URI is likely to be bigger than the MTU.

Do you assume a use case in which the total length of options is going
to be greater than the MTU ?

One possible solution is that a fragment option is defined and is placed
at the first than other options.  And, However, the option number has a
semantic, and the order of the options is settled.  There is no room for
the block options to be placed at the first.

Shoichi

Re: IETF 86 Admin Plenary Minutes

[Barry Leiba]

> http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary
>
> Please review and comment.

-
Lorenzo Colitti was wondering what problem we are trying to solve: He
looked at the IESG and they all look the same as the people in the
audience. Is the problem that the people on the IESG don't represent the
people in the audience? Or is the problem that the IETF participants are
not diverse enough. These are two different problems, and they cannot
both be solved with one solution.
-

I understood the beginning of Lorenzo's comment differently.  I
thought he said that when he looked at the stage he saw one version of
(lack of) diversity, and when he looked at the audience he saw a
different version.  That, as I understood it, is what motivated his
question about which of those problems we're aiming at solving.  (In
the version in the minutes, the question in the second sentence
doesn't really make sense after the first sentence.)

Barry

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

[David Farmer]

1) In Section 1, goal #2, "Hierarchical Allocation", I believe a 
reference the definition in RFC 5226 - Section 4.1.  Well-Known IANA 
Policy Definitions, should be considered.


2) I also wonder if another appropriate goal would be explicitly 
defining the ASN and IP address registries using RFC 5226 language 
including the formal linkage to ICANN and the RIRs as the mechanism for 
IANA to implementing the Hierarchical Allocation of these registries. 
See: RFC 5226, section 4.3. "Updating IANA Guidelines for Existing 
Registries"


The intention wouldn't be to override RFC 2860, ICANN Policy, or IR 
global policy, but to provide and explicit formal technical definition 
for these registries that really have only been implicitly defined to 
date as far as I can tell.  There are any number of other registries 
that are far less important overall, that have excellent formal 
technical definitions that comply with RFC 5226 or its predecessors. 
However, these our most important registries have no such formal 
technical definitions, I think its really time to fix this situation.


That said, to the greatest extent possible we need a formal technical 
definition compliant with RFC 5226 of the as-is-state, not of the 
want-it-to-be-state.  Or, if I'm incorrect and there are formal 
technical definitions for these registries that comply with RFC 5226, or 
its predecessors, then they should be referenced in this document.


3) The last paragraph of Section 3, "Internet Numbers Registry Technical 
Considerations"  Says;


   As the Internet and the Internet Numbers Registry System continue to
   evolve, it may be necessary for the Internet community to examine
   these and related technical and operational considerations and how
   best to meet them.

I wonder if it wouldn't be appropriate to at least provide some 
suggestions for how this is to be accomplished.  Maybe request that 
future RFCs related to these technical and operational considerations 
include an applicability statement as to the Internet Numbers Registry 
System, either in a separate section or maybe as a sub-section of the 
IANA Considerations.



On 3/16/13 17:13 , Russ Housley wrote:

A new, I-D, draft-housley-rfc2050bis-00.txt, has been posted.  I am writing to 
ask for your review.

Russ


--

David Farmer   Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952

Re: Getting rid of the dot (was: Mentoring)

[Jeffrey Haas]

On Mon, Mar 18, 2013 at 11:10:14PM +0100, Carsten Bormann wrote:
> I wouldn't mind replacing my blue dot with an indication *what* WG I chair, 
> and in which area that is.
> 
> Might be a bit more logistics when chairs change, but nothing that can't be 
> solved with a DYMO labelmaker.

Since I live with a graphic designer, I occasionally think about arranging
for some stickers that convey what areas one follows.  I suspect dinner
conversation at some point will involve trying to figure out appropriate
icons for the different areas.  Routing is the only immediately obvious one
to me.

INT, TSV, OPS and APP may simply suffer from my poor imagination with some
sort of ROYGBIV style 7-layer stack with those groups indicated by their
appropriate place in the hierarchy.  (Although OPS may object to my 
"layer 6" thinking. :-)

Such an exercise would probably generate a lot less controversy than my
unsanctioned badge experiment.

http://pfrc.org/~jhaas/pictures/badge.jpg


-- Jeff

Re: Getting rid of the dot

[Spencer Dawkins]

On 3/18/2013 5:04 PM, SM wrote:


At 13:49 18-03-2013, Spencer Dawkins wrote:

There are dots, and then there are dots. The one I'd like to see
continued the most is the orange dot, for Nomcom members. We choose
the voting members at random out of a volunteer pool, with some
qualifications but not a lot, for a specific duration. Perhaps there's
value in helping the community identify Nomcom members quickly during
breaks, etc.


Did you need to look for the NomCom dot to identify NomCom members? :-)


Hi, SM,

Not me, even when I don't recognize half the names of voting members, 
because I "identify NomCom members" by sending a request for an 
interview slot (and I'm remembering that these are 30 minutes long), so 
everyone in the room when I arrive is a NomCom member ;-)


That's OK for people who can provide input on lots of people - I do - 
but doesn't scale for people who just want to provide input on a couple 
of people they've worked with, who are willing nominees for a 
NomCom-selected position. Grabbing someone who has to listen because 
they're chewing a cookie can be enough, sometimes!


Spencer

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

[Robert Sparks]

On 3/15/13 1:40 PM, Dale R. Worley wrote:

From: Christopher Morrow 

curious why rsync doesn't also seem 'straightforward' and 'well
supported' ?

Is this an advocacy of a particular tool?  Or are you asserting that
rsync can be used to maintain a directory of RFCs?  If the latter,
could you supply some details (including, especially, how to get at
the public repository)?
 -> 



alternatively, look at the third section on the right column at 


(starting with "Download the latest documents")

RjS



Dale

Re: Getting rid of the dot (was: Mentoring)

[Carsten Bormann]

I wouldn't mind replacing my blue dot with an indication *what* WG I chair, and 
in which area that is.

Might be a bit more logistics when chairs change, but nothing that can't be 
solved with a DYMO labelmaker.

Grüße, Carsten

Getting rid of the dot (was: Mentoring)

[SM]

Hi Spencer,
At 13:49 18-03-2013, Spencer Dawkins wrote:
There are dots, and then there are dots. The one I'd like to see 
continued the most is the orange dot, for Nomcom members. We choose 
the voting members at random out of a volunteer pool, with some 
qualifications but not a lot, for a specific duration. Perhaps 
there's value in helping the community identify Nomcom members 
quickly during breaks, etc.


Did you need to look for the NomCom dot to identify NomCom members? :-)

If the IAOC continues to hold open sessions at future IETF meetings, 
that's good; if not, perhaps there's value in helping the community 
identify IAOC members quickly, too.


If the community cannot identify these IAOC members quickly it can 
only mean that these members are unknown or known to a selected few 
who have been attending meetings since several years.


attendees lists and meeting wikis, and a larger and more visible 
secretariat, green dots may have more value as recognition for 
meeting sponsors (and if giving out green dots matters to people who 
support the IETF financially, that's certainly sufficient as a 
reason to keep them!).


Yes.

Just keep thinking carefully, as people are doing, and developing a 
better understanding about what we are doing and why it might have 
been our practice in the past ... and whether it's still a good idea now.


Agreed.

Regards,
-sm 

IETF 86 Admin Plenary Minutes

[Russ Housley]

http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary

Please review and comment.

Russ

Re: Mentoring

[Spencer Dawkins]

On 3/18/2013 2:34 PM, Arturo Servin wrote:


Yes and no.

I would get rid of all the dots, possible yes.


In general, I like the scope of what's being questioned in the past week 
or so, even if the answer comes back "we talked about this, and the 
other stuff we could think of was worse" :-)


On dots, specifically ... I'm guessing from context that you're thinking 
red/IAB, yellow/IESG, blue/WG chairs, and possibly pink (technically the 
IRSG, but almost all the IRSG members are also RG chairs, so in this 
case, pink is like yellow and blue, mixed together).


There are dots, and then there are dots. The one I'd like to see 
continued the most is the orange dot, for Nomcom members. We choose the 
voting members at random out of a volunteer pool, with some 
qualifications but not a lot, for a specific duration. Perhaps there's 
value in helping the community identify Nomcom members quickly during 
breaks, etc.


For several years, I've scheduled meetings with Nomcom during their 
office hours, but I'm usually providing input on 10-20 willing nominees. 
It might be helpful for someone to chat with a Nomcom member and give 
feedback on one or two willing nominees in just a few minutes - that's 
what I'm talking about.


If the IAOC continues to hold open sessions at future IETF meetings, 
that's good; if not, perhaps there's value in helping the community 
identify IAOC members quickly, too.


For extra credit, picking a color that's easier to identify distinctly 
would help (I can't consistently tell the difference between 
"purple/IAOC member" and "blue/WG Chair" unless someone is wearing both).


IIRC, the green Local Host dots were intended to help people who weren't 
familiar with a meeting site find someone who was familiar with that 
site. Now that we have an IAOC, and attendees lists and meeting wikis, 
and a larger and more visible secretariat, green dots may have more 
value as recognition for meeting sponsors (and if giving out green dots 
matters to people who support the IETF financially, that's certainly 
sufficient as a reason to keep them!).


Just keep thinking carefully, as people are doing, and developing a 
better understanding about what we are doing and why it might have been 
our practice in the past ... and whether it's still a good idea now.


Thanks,

Spencer


The new attendee tag, not sure. May change it for a dot.

The tags is useful to identify new people and help. A mentor tag or dot
would be useful to people for not thinking that you are a weirdo trying
to make conversation.

We need to get rid of old traditions if they do not longer apply, but
also we need to subtle identify people willing to help and people that
may need some help.

Regards,
as

On 3/18/13 3:14 PM, SM wrote:


I would get rid of the dots.  It seems that the IETF has been
perpetuating rituals for no reason other than it is tradition (it is how
things were done before).  I would get rid of the "new attendee" tag as
it creates different categories of individuals.

Re: Mentoring

[Arturo Servin]

Yes and no.

I would get rid of all the dots, possible yes.

The new attendee tag, not sure. May change it for a dot.

The tags is useful to identify new people and help. A mentor tag or dot
would be useful to people for not thinking that you are a weirdo trying
to make conversation.

We need to get rid of old traditions if they do not longer apply, but
also we need to subtle identify people willing to help and people that
may need some help.

Regards,
as

On 3/18/13 3:14 PM, SM wrote:
> 
> I would get rid of the dots.  It seems that the IETF has been
> perpetuating rituals for no reason other than it is tradition (it is how
> things were done before).  I would get rid of the "new attendee" tag as
> it creates different categories of individuals.

Re: raw meeting minutes (Re: meetecho praise)

[Simon Pietro Romano]

Hi,

we have used an etherpad-enabled Meetecho room  
(https://twitter.com/spromano/status/311211960412807169/photo/1) during the 
History BoF at IETF86 and I have to say that the shared editor worked like a 
charm. In my personal view, this is an extremely useful tool for minute-taking.

Simon


Il giorno 18/mar/2013, alle ore 18:57, Jeffrey Haas ha scritto:

> On Mon, Mar 18, 2013 at 09:35:49AM -0700, Dave Crocker wrote:
>> If minutes takers used etherpad, the raw minutes would be available
>> in real-time, rather than requiring everyone to wait for the
>> polished version.
> 
> When it's working, I prefer to use etherpad.  It was down during the first
> SIDR session.  Lest I seem like I'm griping about a single problem, it seems
> to be down at least once an IETF when I'm wanting to contribute notes.
> 
> Great tool, but some issues seem to still be there.
> 
> -- Jeff
> 

   _\\|//_
  ( O-O )
   ~~o00~~(_)~~00o
Simon Pietro Romano
 Universita' di Napoli Federico II
 Computer Engineering Department 
 Phone: +39 081 7683823 -- Fax: +39 081 7683816
   e-mail: sprom...@unina.it

<>. Magritte.
 oooO
  ~~~(   )~~~ Oooo~
 \ ((   )
  \_)  ) /
   (_/

Re: Mentoring

[SM]

At 06:44 18-03-2013, Carlos M. Martinez wrote:

- I support a newcomers' list. However, I do believe that the definition
of newcomer must be relaxed a bit. A newcomer is not a 'first time
attendee'. Being a IETF youngster I would say that for the first three
meetings you are a newcomer. This may vary, but if I had to draw a line
somewhere, three would be my choice.


I suggest calling the mailing list hall...@ietf.org or else use 
edu-t...@ietf.org.  I don't see any reason why "new" has to be defined.



- Breakfasts / lunch meetings are great, but they are not enough. These
slots might need some augmentation. I don't have many ideas except
dinners and parallel slots while the WGs sessions are in progress.


I suggest increasing the duration of the breaks.  If you formalize a 
lunch meeting, for example, it will be engineered for perfection.  It 
will end up being uninteresting (see Meet-and-Greet thread).



- However tempting, I don't think ADs  / WG chairs are ideal mentoring
choices. During the IETF week they are drenched in work with their "area
directoring"/ "working group chairing" duties and most of them won't
have a lot of time for meeting newcomers and attending to their needs.


Yes.


- Mentors SHOULD be notified of their duties within reasonable time, and
preferably be introduced to their 'pupils' via private email. I don't
know how hard this would be to implement, but it would definitely help.
Another thing to keep in mind: Do all newcomers want being mentored? I
can think of one or two cases I know personally that probably wouldn't
want a mentor.


Seiichi Kawamura mentioned that it is about peer environment.  The 
idea of mentorship seems to be about having new people listening 
religiously to old people explaining how things should work.  If the 
IETF thinks that it is a good idea I will opt out as I believe that I 
will be considering people are inferior if I do that.



- Moving the newcomers reception to later in the week is a MUST. Mentors
should obviously be also invited to this reception.


Murray Kucherawy mentioned that newcomers reception is used to take 
care of business (the people who regularly attend meetings discuss 
about IETF work).


At 05:42 18-03-2013, Jari Arkko wrote:

Not sure if that should be the winners or losers :-)


I don't like the idea of winners and losers.

Seriously though, I am roughly in the same camp as Seiichi. The real 
introduction of someone into the IETF is mostly about finding 
discussion partners around the reason why the person came to the 
IETF to begin with. Most of the time these would be peers within a 
working group. Like-minded vendors, customers or researchers. Not 
everyone who comes to the IETF for the first time is a beginner, 
they may for instance be established engineers on their fields, and 
just coming to the IETF to accomplish a goal. We discuss very
 interesting topics at the IESG and IAB, but I think the more 
direct way to introduce someone to the IETF "network" is to connect 
the person with others who work in the same topic. And maybe create 
some real co-operation between those people, building additional 
reasons for the person to continue to join our meetings.


Agreed.

As an aside, from personal experience, small, targeted meetings with 
newcomers have tended to work better for me than otherwise.


Yes.

I would get rid of the dots.  It seems that the IETF has been 
perpetuating rituals for no reason other than it is tradition (it is 
how things were done before).  I would get rid of the "new attendee" 
tag as it creates different categories of individuals.


Regards,
-sm

P.S. "If your system of finding people to hire, speakers for your 
stage, or members for your board depends on having them step forward 
and ask, you've effectively institutionalized a bias." 

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

[Arturo Servin]

Policy Manual / v1.10 - 13/08/2012

1. Definitions
http://www.lacnic.net/en/web/lacnic/manual-1

2. IPv4 Addresses
http://www.lacnic.net/en/web/lacnic/manual-2

etc ...

And it is not administration/control, it is also about service
(language, timezones, etc.)

/as

On 3/18/13 2:44 PM, Roger Jørgensen wrote:

> 
> 
> 
> I see APNIC are using it
> (http://www.apnic.net/policy/operational-policies-nirs/text), are
> anyone else? All I see is just yet another level of
> administration/control?
> 
> 
> 

Re: raw meeting minutes (Re: meetecho praise)

[Jeffrey Haas]

On Mon, Mar 18, 2013 at 09:35:49AM -0700, Dave Crocker wrote:
> If minutes takers used etherpad, the raw minutes would be available
> in real-time, rather than requiring everyone to wait for the
> polished version.

When it's working, I prefer to use etherpad.  It was down during the first
SIDR session.  Lest I seem like I'm griping about a single problem, it seems
to be down at least once an IETF when I'm wanting to contribute notes.

Great tool, but some issues seem to still be there.

-- Jeff

Re: raw meeting minutes (Re: meetecho praise)

[John Levine]

>It would also allow some crows-sourcing of corrections and additions to 
>the raw minutes...

CAW CAW CAW CAW !!!

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

[Roger Jørgensen]

On Mon, Mar 18, 2013 at 5:20 PM, joel jaeggli  wrote:
> 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.

As much as I dislike the entire term NIR I see it exist already on the
"top"/"root", to quote from http://www.iana.org/numbers

"Both IPv4 and IPv6 addresses are generally assigned in a hierarchical
manner. Users are assigned IP addresses by Internet service providers
(ISPs). ISPs obtain allocations of IP addresses from a local Internet
registry (LIR) or National Internet Registry (NIR), or from their
appropriate Regional Internet Registry (RIR):"



I see APNIC are using it
(http://www.apnic.net/policy/operational-policies-nirs/text), are
anyone else? All I see is just yet another level of
administration/control?



-- 

Roger Jorgensen   | ROJO9-RIPE
rog...@gmail.com  | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no

Re: raw meeting minutes (Re: meetecho praise)

[alejandroacostaalamo]

Hi, 
  Just my two cents: The very few times I've been minute taker it worked very 
well. Probably the problem might be when there is more than one minute taker 
using Etherpad at the same time.

Alejandro,

Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet

-Original Message-
From: Lou Berger 
Sender: ietf-boun...@ietf.org
Date: Mon, 18 Mar 2013 13:00:31 
To: ; Mary Barnes; Dave 
Crocker
Cc: IETF-Discussion list
Subject: Re: raw meeting minutes (Re: meetecho praise)

Etherpad is an awesome tool and we've found out to be hugely useful over a 
number of IETFs, but be forewarned that on a couple of rare occasions the 
notes have disappeared. In the first case, it took a manual step for it to 
be restored.  In the second we had a private copy...

Lou



On March 18, 2013 12:35:49 PM Dave Crocker  wrote:
>
> On 3/18/2013 9:28 AM, Mary Barnes wrote:
> > it seems to take
> > a long time for many to get their meeting minutes uploaded.  My
> > suggestion is for chairs to at least upload the raw minutes as drafts
>
>
> If minutes takers used etherpad, the raw minutes would be available in 
> real-time, rather than requiring everyone to wait for the polished version.
>
> It would also allow some crows-sourcing of corrections and additions to the 
> raw minutes...
>
> d/
>
> --
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>

Re: raw meeting minutes (Re: meetecho praise)

[Lou Berger]

Etherpad is an awesome tool and we've found out to be hugely useful over a 
number of IETFs, but be forewarned that on a couple of rare occasions the 
notes have disappeared. In the first case, it took a manual step for it to 
be restored.  In the second we had a private copy...


Lou



On March 18, 2013 12:35:49 PM Dave Crocker  wrote:


On 3/18/2013 9:28 AM, Mary Barnes wrote:
> it seems to take
> a long time for many to get their meeting minutes uploaded.  My
> suggestion is for chairs to at least upload the raw minutes as drafts


If minutes takers used etherpad, the raw minutes would be available in 
real-time, rather than requiring everyone to wait for the polished version.


It would also allow some crows-sourcing of corrections and additions to the 
raw minutes...


d/

--
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

raw meeting minutes (Re: meetecho praise)

[Dave Crocker]

On 3/18/2013 9:28 AM, Mary Barnes wrote:

it seems to take
a long time for many to get their meeting minutes uploaded.  My
suggestion is for chairs to at least upload the raw minutes as drafts



If minutes takers used etherpad, the raw minutes would be available in 
real-time, rather than requiring everyone to wait for the polished version.


It would also allow some crows-sourcing of corrections and additions to 
the raw minutes...


d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: meetecho praise

[Mary Barnes]

I've added the links to my WG meeting minutes.  I think that's a
better place to store these, although, unfortunately, it seems to take
a long time for many to get their meeting minutes uploaded.  My
suggestion is for chairs to at least upload the raw minutes as drafts
and include the Meetecho links.  Certainly, you have to remember to
finalize the minutes.  But, something is much better than nothing for
folks trying to work forward from the meeting.

Regards,
Mary
CLUE and DISPATCH WG chair

On Mon, Mar 18, 2013 at 11:19 AM, Arturo Servin  wrote:
>
> I looked at the WG's agendas of some meetings that I missed and none
> have a link to the meetecho's recording (they have the audio and
> jabber), which was odd to me (or I had very bad luck to miss the only
> non-meetcho meetings.)
>
> Then I found the recordings at:
>
> http://www.ietf.org/meeting/86/remote-participation.html#Meetecho
>
> I would suggest to add these links to the agenda's WG pages.
>
> Thanks!
> as
>
> On 3/18/13 1:09 PM, Simon Pietro Romano wrote:
>> Hi,
>>
>> on behalf of the Meetecho team, let me just thank you all for your
>> feedback and appreciation :-). We're glad you found Meetecho useful both
>> during the meeting and for off-line access to the recorded sessions.
>>
>> Cheers,
>>
>> Simon
>>
>> Mary Barnes  ha scritto:
>>
>> On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson  
>> wrote:
>>
>> Hello.
>>
>> I would just like to say I'm very grateful for the WGs that used
>> Meetecho to
>> record their sessions. The HTML5 versions works out of the box
>> with no
>> plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on
>> my Windows7
>> machine. The sync of sound, slides, picture and jabber room is
>> excellent and
>> makes it very easy top follow what's going on. Some other
>> recordings focus
>> too much on the video of the speaker, where I'm of the opinion
>> that it's the
>> slides and the sound that is most important, and current
>> incarnation of
>> Meetecho solves this very nicely.
>>
>> I applaud these efforts and hope we can end up in a si! tuation
>> where all
>> meetings at the IETF is recorded in this way.
>>
>> [MB] That would be wonderful. I find Meetecho fantastic for going back
>> and re-reviewing the meeting in cases where notes aren't complete.  As
>> a chair, it's really hard to take good notes and it's sometimes hard
>> for participants as they are sometimes to engage in discussions.  The
>> Meetecho team works extremely hard during these meetings and
>> definitely deserve applause for their work.
>> [/MB]
>>
>> Thanks.
>>
>> --
>> Mikael Abrahamsson email: swm...@swm.pp.se
>>
>>

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: meetecho praise

[Arturo Servin]

I looked at the WG's agendas of some meetings that I missed and none
have a link to the meetecho's recording (they have the audio and
jabber), which was odd to me (or I had very bad luck to miss the only
non-meetcho meetings.)

Then I found the recordings at:

http://www.ietf.org/meeting/86/remote-participation.html#Meetecho

I would suggest to add these links to the agenda's WG pages.

Thanks!
as

On 3/18/13 1:09 PM, Simon Pietro Romano wrote:
> Hi,
> 
> on behalf of the Meetecho team, let me just thank you all for your
> feedback and appreciation :-). We're glad you found Meetecho useful both
> during the meeting and for off-line access to the recorded sessions.
> 
> Cheers,
> 
> Simon
> 
> Mary Barnes  ha scritto:
> 
> On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson  
> wrote:
> 
> Hello.
> 
> I would just like to say I'm very grateful for the WGs that used
> Meetecho to
> record their sessions. The HTML5 versions works out of the box
> with no
> plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on
> my Windows7
> machine. The sync of sound, slides, picture and jabber room is
> excellent and
> makes it very easy top follow what's going on. Some other
> recordings focus
> too much on the video of the speaker, where I'm of the opinion
> that it's the
> slides and the sound that is most important, and current
> incarnation of
> Meetecho solves this very nicely.
> 
> I applaud these efforts and hope we can end up in a si! tuation
> where all
> meetings at the IETF is recorded in this way.
> 
> [MB] That would be wonderful. I find Meetecho fantastic for going back
> and re-reviewing the meeting in cases where notes aren't complete.  As
> a chair, it's really hard to take good notes and it's sometimes hard
> for participants as they are sometimes to engage in discussions.  The
> Meetecho team works extremely hard during these meetings and
> definitely deserve applause for their work.
> [/MB]
> 
> Thanks.
> 
> --
> Mikael Abrahamsson email: swm...@swm.pp.se
> 
> 

Re: meetecho praise

[Simon Pietro Romano]

Hi,

on behalf of the Meetecho team, let me just thank you all for your feedback and 
appreciation  :-). We're glad you found Meetecho useful both during the meeting 
and for off-line access to the recorded sessions.

Cheers,

Simon

Mary Barnes  ha scritto:

>On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson 
>wrote:
>>
>> Hello.
>>
>> I would just like to say I'm very grateful for the WGs that used
>Meetecho to
>> record their sessions. The HTML5 versions works out of the box with
>no
>> plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my
>Windows7
>> machine. The sync of sound, slides, picture and jabber room is
>excellent and
>> makes it very easy top follow what's going on. Some other recordings
>focus
>> too much on the video of the speaker, where I'm of the opinion that
>it's the
>> slides and the sound that is most important, and current incarnation
>of
>> Meetecho solves this very nicely.
>>
>> I applaud these efforts and hope we can end up in a situation where
>all
>> meetings at the IETF is recorded in this way.
>[MB] That would be wonderful. I find Meetecho fantastic for going back
>and re-reviewing the meeting in cases where notes aren't complete.  As
>a chair, it's really hard to take good notes and it's sometimes hard
>for participants as they are sometimes to engage in discussions.  The
>Meetecho team works extremely hard during these meetings and
>definitely deserve applause for their work.
>[/MB]
>>
>> Thanks.
>>
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: meetecho praise

[Spencer Dawkins]

What Mary said, especially from a chair perspective.

I stepped down as co-chair of three working groups just as the Meetecho 
team reached cruising speed, but they were very active in MediaCtrl and 
we benefited considerably from using an early version in Hiroshima. If I 
was co-chairing three working groups today, I would already have sent 
them my request for support in Berlin :-)


Thanks, guys, for all that you do!

Spencer

On 3/18/2013 10:39 AM, Mary Barnes wrote:

On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson  wrote:


Hello.

I would just like to say I'm very grateful for the WGs that used Meetecho to
record their sessions. The HTML5 versions works out of the box with no
plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7
machine. The sync of sound, slides, picture and jabber room is excellent and
makes it very easy top follow what's going on. Some other recordings focus
too much on the video of the speaker, where I'm of the opinion that it's the
slides and the sound that is most important, and current incarnation of
Meetecho solves this very nicely.

I applaud these efforts and hope we can end up in a situation where all
meetings at the IETF is recorded in this way.

[MB] That would be wonderful. I find Meetecho fantastic for going back
and re-reviewing the meeting in cases where notes aren't complete.  As
a chair, it's really hard to take good notes and it's sometimes hard
for participants as they are sometimes to engage in discussions.  The
Meetecho team works extremely hard during these meetings and
definitely deserve applause for their work.
[/MB]


Thanks.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: meetecho praise

[Dhruv Dhody]

I agree whole heartedly as well, this was my first meeting with remote
participation and the experience is definitely better compared to handling
jabber / slides / voice streaming in three different applications.

Bravo Meetecho team!!

Dhruv


On Mon, Mar 18, 2013 at 9:09 PM, Mary Barnes wrote:

> On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson 
> wrote:
> >
> > Hello.
> >
> > I would just like to say I'm very grateful for the WGs that used
> Meetecho to
> > record their sessions. The HTML5 versions works out of the box with no
> > plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my
> Windows7
> > machine. The sync of sound, slides, picture and jabber room is excellent
> and
> > makes it very easy top follow what's going on. Some other recordings
> focus
> > too much on the video of the speaker, where I'm of the opinion that it's
> the
> > slides and the sound that is most important, and current incarnation of
> > Meetecho solves this very nicely.
> >
> > I applaud these efforts and hope we can end up in a situation where all
> > meetings at the IETF is recorded in this way.
> [MB] That would be wonderful. I find Meetecho fantastic for going back
> and re-reviewing the meeting in cases where notes aren't complete.  As
> a chair, it's really hard to take good notes and it's sometimes hard
> for participants as they are sometimes to engage in discussions.  The
> Meetecho team works extremely hard during these meetings and
> definitely deserve applause for their work.
> [/MB]
> >
> > Thanks.
> >
> > --
> > Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: meetecho praise

[Mary Barnes]

On Mon, Mar 18, 2013 at 5:04 AM, Mikael Abrahamsson  wrote:
>
> Hello.
>
> I would just like to say I'm very grateful for the WGs that used Meetecho to
> record their sessions. The HTML5 versions works out of the box with no
> plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my Windows7
> machine. The sync of sound, slides, picture and jabber room is excellent and
> makes it very easy top follow what's going on. Some other recordings focus
> too much on the video of the speaker, where I'm of the opinion that it's the
> slides and the sound that is most important, and current incarnation of
> Meetecho solves this very nicely.
>
> I applaud these efforts and hope we can end up in a situation where all
> meetings at the IETF is recorded in this way.
[MB] That would be wonderful. I find Meetecho fantastic for going back
and re-reviewing the meeting in cases where notes aren't complete.  As
a chair, it's really hard to take good notes and it's sometimes hard
for participants as they are sometimes to engage in discussions.  The
Meetecho team works extremely hard during these meetings and
definitely deserve applause for their work.
[/MB]
>
> Thanks.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: meetecho praise

[Alejandro Acosta]

Hi,
  I want to support Mikael's comment.
  Meetecho worked really well, I used to connect using a regular
jabber client however using Meetecho really enriches the experience,
it was very nice to see the slides, to be in the jabber room,
everything in the same screen. I also had audio (In a previous
recording I also had video).
  I did not use html5 and my audio was using VLC. I got small two
problems: my company's firewall blocked the output port to connect to,
so I needed to create a special rule on it. Video was not available
but I'm not sure because of the WG room or maybe another issue. Anyway
audio was good (as usual it can always be better).

Thanks,

Alejandro,



On 3/18/13, Mikael Abrahamsson  wrote:
>
> Hello.
>
> I would just like to say I'm very grateful for the WGs that used Meetecho
> to record their sessions. The HTML5 versions works out of the box with no
> plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my
> Windows7 machine. The sync of sound, slides, picture and jabber room is
> excellent and makes it very easy top follow what's going on. Some other
> recordings focus too much on the video of the speaker, where I'm of the
> opinion that it's the slides and the sound that is most important, and
> current incarnation of Meetecho solves this very nicely.
>
> I applaud these efforts and hope we can end up in a situation where all
> meetings at the IETF is recorded in this way.
>
> Thanks.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: [apps-discuss] Last Call: (WebFinger) to Proposed Standard

[Alissa Cooper]

Given how little control Internet users already have over which information 
about them appears in which context, I do not have a lot of confidence that the 
claimed discoverability benefits of WebFinger outweigh its potential to further 
degrade users' ability to keep particular information about themselves within 
specific silos. However, I'm coming quite late to this document, so perhaps 
that balancing has already been discussed, and it strikes me as unreasonable to 
try to stand in the way of publication at this point.

Two suggestions in section 8:

s/personal information/personal data/
(see http://tools.ietf.org/html/draft-iab-privacy-considerations-06#section-2.2 
-- personal data is a more widely accepted term and covers a larger range of 
information about people)

The normative prohibition against using WebFinger to publish personal data 
without authorization is good, but the notion of implicit authorization leaves 
much uncertainty about what I imagine will be a use case of interest: taking 
information out of a controlled context and making it more widely available. To 
make it obvious that this has been considered, I would suggest adding one more 
sentence to the end of the fourth paragraph:

"Publishing one's personal data within an access-controlled or otherwise 
limited environment on the Internet does not equate to providing implicit 
authorization of further publication of that data via WebFinger."

Alissa

On Mar 4, 2013, at 3:24 PM, The IESG  wrote:

> 
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'WebFinger'
>   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-03-18. 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 specification defines the WebFinger protocol, which can be used
>   to discover information about people or other entities on the
>   Internet using standard HTTP methods.  WebFinger discovers
>   information for a URI that might not be usable as a locator
>   otherwise, such as account or email URIs.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> ___
> apps-discuss mailing list
> apps-disc...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

[Michael Richardson]

https://github.com/credil/ietf-drafts-sorted
  is the result of my "draftmirror" script which basically does s,-,/,
  in a selective way.  Each author and group gets its own directory.

  Previously I have just run draftmirror on each of my devices, but
  now, I think I'll just use git pull, so I saved the world some bandwidth.
  
https://github.com/credil/ietf-drafts
  is the unsorted rsync.

I probably have to sort out what ssh key I use to push.

-- 
Michael Richardson , Sandelman Software Works 




pgp4bKX0sVf11.pgp
Description: PGP signature

Re: Mentoring

[Carlos M. Martinez]

Not answering any specific email, just establishing position:

- I support a newcomers' list. However, I do believe that the definition
of newcomer must be relaxed a bit. A newcomer is not a 'first time
attendee'. Being a IETF youngster I would say that for the first three
meetings you are a newcomer. This may vary, but if I had to draw a line
somewhere, three would be my choice.

- Breakfasts / lunch meetings are great, but they are not enough. These
slots might need some augmentation. I don't have many ideas except
dinners and parallel slots while the WGs sessions are in progress.

- However tempting, I don't think ADs  / WG chairs are ideal mentoring
choices. During the IETF week they are drenched in work with their "area
directoring"/ "working group chairing" duties and most of them won't
have a lot of time for meeting newcomers and attending to their needs.

- Mentors SHOULD be notified of their duties within reasonable time, and
preferably be introduced to their 'pupils' via private email. I don't
know how hard this would be to implement, but it would definitely help.
Another thing to keep in mind: Do all newcomers want being mentored? I
can think of one or two cases I know personally that probably wouldn't
want a mentor.

- Moving the newcomers reception to later in the week is a MUST. Mentors
should obviously be also invited to this reception.

Warm regards,

~Carlos

On 3/14/13 9:30 AM, Adrian Farrel wrote:
> Mary,
> 
> I need to check but...
> 
>> [MB]  What I find interesting is that there was 200+ newcomers, but I
>> certainly didn't find that many at the meet and greet.  I have to
>> wonder whether this doesn't have to do with the overlap between Sunday
>> tutorials and this event.  I think that needs to be fixed.
> 
> Very right that it would need to be fixed, but I thought that it was avoided 
> explicitly and 
> deliberately. Anyone got a copy of the agenda in front of them?
> 
> Maybe we could do a little research on why newcomers don't show at this 
> meeting. Are they tired? 
> Shy? Unaware? Not perceiving the value?
> 
> Adrian
> 

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

[Ole Jacobsen]

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?

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: Mentoring

[Jari Arkko]

John,

> 
> Fine plan if we can put a stop to having breakfast and lunch be
> the prime target for assorted management and coordination
> meetings.

Yes.

> I would, however, favor conducting a lottery among, say,
> first-year attendees (but not first time unless they qualified
> by useful mailing list participation -- see my earlier comment
> and Spencer's response)-- and inviting the winners to sit in on
> IESG or IAB breakfast meeting,

Not sure if that should be the winners or losers :-)

Seriously though, I am roughly in the same camp as Seiichi. The real 
introduction of someone into the IETF is mostly about finding discussion 
partners around the reason why the person came to the IETF to begin with. Most 
of the time these would be peers within a working group. Like-minded vendors, 
customers or researchers. Not everyone who comes to the IETF for the first time 
is a beginner, they may for instance be established engineers on their fields, 
and just coming to the IETF to accomplish a goal. We discuss very interesting 
topics at the IESG and IAB, but I think the more direct way to introduce 
someone to the IETF "network" is to connect the person with others who work in 
the same topic. And maybe create some real co-operation between those people, 
building additional reasons for the person to continue to join our meetings.

Anyway, this is a great thread. Plenty of ideas to consider. 
Sometime-later-than-Sunday sounds an interesting proposal, so do the WG 
breakfasts. In any case, scheduling is typically difficult with any approach we 
take. I also liked the beer motivator idea :-) and ideas about better ways to 
reach the newcomers. 

As an aside, from personal experience, small, targeted meetings with newcomers 
have tended to work better for me than otherwise.

Jari

Re: meetecho praise

[alejandroacostaalamo]

Hi all,
  I would like to join Mikael's words.
  I used to connect using a regular jabber client but the experience with 
meetecho is much better. Having audio, chat room  and the slides is fantastic.
  I did not use the html5 version so my audio was using vlc, I had to modify 
our firewall rules becase the destionation port was blocked. Audio was very 
good (it can always be better of course).

Thanks,
 


Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet

-Original Message-
From: Mikael Abrahamsson 
Sender: ietf-boun...@ietf.org
Date: Mon, 18 Mar 2013 11:04:06 
To: 
Subject: meetecho praise


Hello.

I would just like to say I'm very grateful for the WGs that used Meetecho 
to record their sessions. The HTML5 versions works out of the box with no 
plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my 
Windows7 machine. The sync of sound, slides, picture and jabber room is 
excellent and makes it very easy top follow what's going on. Some other 
recordings focus too much on the video of the speaker, where I'm of the 
opinion that it's the slides and the sound that is most important, and 
current incarnation of Meetecho solves this very nicely.

I applaud these efforts and hope we can end up in a situation where all 
meetings at the IETF is recorded in this way.

Thanks.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

RE: recognition

[Dearlove, Christopher (UK)]

Perhaps there should be a gold dot for past service. Maybe a silver dot for ten 
years, a gold dot for twenty.

(Slightly non-serious, but also slightly serious.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearl...@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Jari 
Arkko
Sent: 15 March 2013 13:40
To:  list
Cc: Ralph Droms (rdroms)
Subject: recognition

--! WARNING ! --
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.


I wanted to give recognition to someone. As Ralph Droms stepped down from the 
IESG this week, he completed 24 continuous years of service in the leadership 
of the IETF, with a dot on his badge. The last four years he has been one of 
the INT ADs, and before that he chaired the DHC working group for 20 years (!). 
Thank you Ralph for everything you have done! 

If you see Ralph in the hallway, please stop and thank him for his service and 
contributions with DHCP and many, many other things.

The proceedings of the first meeting of the DHC WG are here: 
http://www.ietf.org/proceedings/13.pdf (page 59).

Jari Arkko
IETF Chair




This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

meetecho praise

[Mikael Abrahamsson]

Hello.

I would just like to say I'm very grateful for the WGs that used Meetecho 
to record their sessions. The HTML5 versions works out of the box with no 
plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my 
Windows7 machine. The sync of sound, slides, picture and jabber room is 
excellent and makes it very easy top follow what's going on. Some other 
recordings focus too much on the video of the speaker, where I'm of the 
opinion that it's the slides and the sound that is most important, and 
current incarnation of Meetecho solves this very nicely.


I applaud these efforts and hope we can end up in a situation where all 
meetings at the IETF is recorded in this way.


Thanks.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Last Call: (WebFinger) to Proposed Standard

[Stephane Bortzmeyer]

On Mon, Mar 04, 2013 at 12:24:24PM -0800,
 The IESG  wrote 
 a message of 33 lines which said:

> - 'WebFinger'
>as Proposed Standard

This is a very important protocol (we need a standard way to get
information about people and other entities, which do not rely on a
central closed silo). I've read the draft carefully and I believe it
is mostly OK.

However, I reported two problems to the webfinger mailing list and I
believe they require a new version of the I-D. One is the wrong tag
for the default language (zero comments on the mailing list) and one
is the lack of details on the matching of URIs (it seems there is a
consensus on the mailing list to add a reference to a specific
algorithm of RFC 3986).

(A smaller problem is an imperfect example of language tags.)

Re: I-D Action: draft-housley-rfc2050bis-00.txt

[Brian E Carpenter]

I think this draft is in a good state and says what needs to be said.

One point is that, assuming we conclude that it should not be a BCP,
this should probably be mentioned, for example in section 5. RFC 2050
contains an IESG note explaining why it was published as a BCP; it
would be logical for the replacement to explain why it isn't. IMHO,
it is RFC 2860 that makes BCP status inappropriate.

Nit: there are numerous unused references (even RFC 2050 itself).

Regards
   Brian Carpenter