Re: Radical Solution for remote participants

[Andy Bierman]

Hi,

+1

On Fri, Aug 16, 2013 at 1:59 AM, Joel M. Halpern  wrote:
> Maybe I am missing something.
> The reason we have face-to-face meetings is because there is value in such
> meetings that can not reasonably be achieved in other ways.
> I would like remote participation to be as good as possible.  But if would
> could achieve "the same as being there" then we should seriously consider
> not meeting face-to-face.

Being at the IETF for a week is never going to be the same experience
as participating remotely at a computer for a couple 2 hour meetings.
A lot of work gets done outside the official WG meetings because
the right people can all be in the same room at the same time.

IMO we should be using more virtual interim meetings,
not trying to turn our f2f meetings into remote meetings.
WGs should meet virtually at least once a month for 2 - 4 hours
to make progress on issues same as via the WG mailing list.
Everybody is a remote participant in a virtual interim so
the problems with interfacing to a live meeting go away.

> Conversely, until the technology gets that good, we must not penalize the
> face-to-face meeting for failures of the technology.
>
> Yours,
> Joel


Andy

>
> On 8/15/13 9:48 PM, Mark Nottingham wrote:
>>
>>
>> On 13/08/2013, at 11:00 AM, Douglas Otis  wrote:
>>>
>>>
>>> 1) Ensure exact digital interfaces driving projectors are fully available
>>> remotely.
>>
>>
>> That would be fantastic, if feasible. Much simpler than sharing through
>> software.
>>
>>
>>> 2) Ensure Audio access requires an identified request via XMPP prior to
>>> enabling either a remote or local audio feed.
>>
>>
>> Hm.
>>
>>>
>>> 3) RFI tags could facilitate enabling local audio feed instead of an
>>> identified request via XMPP.
>>
>>
>> Could be quite interesting; many conferences now provide attendees with
>> RFID tags...
>>
>>>
>>> 4) In the event of the local venue loosing Internet access, the device
>>> regulating A/V presentations must be able to operate in a virtual mode where
>>> only remote participants are permitted to continue the meeting proceedings.
>>
>>
>> That seems… extreme.
>>
>>> 5) Important participants should plan for alternative modes of Internet
>>> access to remain part of the proceedings.
>>
>>
>> Not exactly practical.
>>
>>>
>>> 6) Develop a simple syntax used on XMPP sessions to:
>>> 1) signify a request to speak on X
>>> 2) withdraw a request to speak on X
>>> 3) signify support of Y
>>> 4) signify non-support of Y
>>> 5) signal when a request has been granted or revoked.  For local
>>> participants this could be in the form of a red or green light at their
>>> microphone.
>>
>>
>> The W3C does much of this already with IRC bots, e.g.:
>>http://www.w3.org/2001/12/zakim-irc-bot.html
>>
>> (also can pick a scribe, track an agenda, etc.)
>>
>>
>>> 7) Develop a control panel managed by chairs or their proxies that
>>> consolidate and sequence requests and log support and nonsupport indications
>>> and the granting of requests.
>>
>>
>> See above (I think).
>>
>>>
>>> 8) Chairs should be able to act as proxies for local participants lacking
>>> access to XMPP.
>>
>>
>> Not practical, unless they delegate.
>>
>>>
>>> 9) Chairs should have alternative Internet access independent of that of
>>> the venue's.
>>
>>
>> Seems extreme.
>>
>>>
>>> 10) Establish a reasonable fee to facilitate remote participants who
>>> receive credit for their participation equal to that of being local.
>>>
>>> 11) The device regulating A/V presentations must drive both the video and
>>> audio portions of the presentations.  A web camera in a room is a very poor
>>> replacement.
>>>
>>> 12) All video information in the form of slides and text must be
>>> available from the Internet prior to the beginning of the meeting.
>>
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>

Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Andy Bierman]

On Wed, Aug 14, 2013 at 6:07 AM, Carsten Bormann  wrote:
> On Aug 14, 2013, at 13:40, Randy Bush  wrote:
>
>>> YANG seems to be incompatible with CBOR.
>>
>> so what does that say about yang, yang's suitability for netconf, cbor,
>> and cbor's suitability?
>
> Good question.  I'm not sure the jury is even out on that yet.
>
> Yaron reminded me that netconf is using XPath for various purposes, so a CBOR 
> rendition of netconf would need to do the same that you would need for doing 
> netconf with JSON: either replace XPath with something else (indeed causing 
> some incompatibility), or explain how to use XPath with the CBOR/JSON 
> translation of the YANG model (which might be interesting).
>
> CBOR certainly has no trouble carrying around the data described by a YANG 
> model.
> (Indeed, CBOR's decimal fractions were inspired by YANG's.)
> But then, I don't have an opinion whether adding a binary object 
> representation to the netconf ecosystem is on the agenda.
>

I am not sure this is an actual problem.
NETCONF uses full XPath only if the :xpath capability
is supported.  The "select" expression represents
the data to be returned from the conceptual datastore
and possibly the state/statistics within the device.
The select expression is not related to the message on the wire.

There is also an "error-path" field that is returned in errors
that contains the absolute path of the message or data node
that caused the error.

Neither of these message fields should cause an encoding problem.
They are just strings at the message layer.



> Grüße, Carsten
>

Andy

Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Andy Bierman]

On Wed, Aug 14, 2013 at 12:31 AM, Yaron Sheffer  wrote:
> Hi Randy,
>
> I prefer to leave this question to people who know something about Netconf,
> i.e. not me.
>
> But let me just say that, based on my thoroughly extensive 5-min. research,
> YANG seems to be incompatible with CBOR.
>

Can you be more specific?
What is incompatible about YANG?

> Thanks,
> Yaron
>

Andy


> On 2013-08-14 04:53, Randy Presuhn wrote:
>>
>> Hi -
>>
>>> From: Yaron Sheffer 
>>> Sent: Aug 13, 2013 2:11 PM
>>> To: IETF Discussion Mailing List 
>>> Subject: re: Last Call:  (Concise Binary
>>> Object  Representation (CBOR)) to Proposed Standard
>>
>> ...
>>>
>>> - The "diagnostic notation" can be used very effectively for things like
>>> configuration files, e.g. if an application already uses CBOR on the
>>> wire. Therefore I would suggest to formalize it a bit more, so that we
>>> also have interoperability at this level.
>>
>>
>> Do you envision it as an encoding for Netconf?
>>
>> Randy
>>
>

Re: Berlin was awesome, let's come again

[Andy Bierman]

On Tue, Aug 6, 2013 at 3:52 PM, Martin Rex  wrote:
> Ulrich Herberg wrote:
>>
>> I think that the heat was exceptional. I have grown up in Munich, and
>> I have rarely ever seen it that hot (either in Munich or Berlin).
>> Maybe it's global warming? ;-)
>
> Damn coincidences!
>
> IETF 39 was in Munich (August 1997)  Arabella&Sheraton @ Arabella Park,
> and it was HOT pretty much the whole week.
>

Yes -- they said the same thing last time -- no need for ventilation since
it never gets too hot here.  I noticed the locals on the 200 bus to
the beer festival were just as miserable as me.
I stopped in a McDonalds for a diet coke, but the ice machine was broken.
(I was told it was too hot for it to make ice. Since I was the only American
in there, nobody noticed the ice machine didn't work but me ;-)

I would still come back -- this was a great city for an IETF -- I just hope
for once we get normal weather for July.


> -Martin

Andy

Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)

[Andy Bierman]

Hi,

I don't care if this report is published or not, but I will point
out that the 1 week sample period is not that useful if
the intent is to spot excessive posting.

Somebody could be following up on 1 thread, and not post again
for a year.  Somebody could be participating in an IETF Last Call
discussion, which should not even count as "extra" since that is
a critical part of our review process.


Andy


On Sat, Aug 3, 2013 at 12:12 AM, Heasley  wrote:
> Am Aug 3, 2013 um 9:05 schrieb Abdussalam Baryun :
>
>> On 8/3/13, Patrik Fältström  wrote:
>>> On 3 aug 2013, at 08:46, Abdussalam Baryun 
>>> wrote:
>>>
 I prefer if you post at end of Friday (as in the end of working days of 5 
 in each week).
>>
 However, in my comment below I
 will follow the week as done in world calender, start from Sunday
 (mornings) and ends on Saturday (nights).
>>>
>>> The day a week starts, and what days are working days in a week, differs
>>> between cultures. Many have Sunday-Thursday as working days. Many have
>>> Monday as the first day of the week.
>>
>> I suggested to Thomas to submit report in end of Friday (read what i
>
> I suggest eliminating the report. As it doesn't measure content quality, 
> one's contribution can't be measured by the email they produce. So, it is 
> only a guage of  the distraction they produce. The report itself is a 
> distraction.

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir  wrote:
>
> On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:
>
>> Hi,
>>
>> Isn't it obvious why humming is flawed and raising hands works?
>> (Analog vs. digital).  A hand is either raised or it isn't.
>> The sum of all hands raised is comparable across tests.
>> The sum of the amplitude of all hums is not.
>
> Hums are better as they give greater weight to people who are more vocally in 
> support (or in opposition) to the assertion.
>

Please provide some evidence that a loud hum means the person is more
committed to work on an item.

Favoring loud humming is subject to cultural bias.
Some cultures are more inclined to raise their voice than others.
Some people have naturally louder voices than others.
Measuring volume may introduce bias in favor of loud men and against
soft-spoken women, for example.

This cultural bias is not compatible with increased inclusiveness.


Andy

> Research shows([1]), that the one humming loudly for acceptance, will also 
> volunteer to review and contribute code. The one humming loudly against is 
> going to jump up to the mike in all future meetings and tell the group that 
> they're doing the wrong thing. Those who hum softly will go back to reading 
> their email.
>
> Yoav
>
> [1] citation needed
>

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 3:04 AM, manning bill  wrote:
> we have never voted at IETFs.
> "we believe in rough consensus and running code"
>

We are not voting.
We are expressing agreement with a specific assertion.
That is true whether the agreement is expressed via vocalization
or motion of limbs.

Humming allows the chairs to be totally biased and interpret the hum volume
in a way that aligns with their preference for the outcome.

However, I have seen many times where the chairs clearly miscounted
the number of raised hands in order to make the outcome align
with their preference.  However this is much harder to pull off than comparing
2 similar hum volumes.

The chairs can pick however they want to measure agreement.
Many chairs ask for a show of hands.  I prefer that method.
There is still a judgement call when the numbers for and against
are not significantly different.

> /bill

Andy

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

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 2:34 AM, Ralph Droms  wrote:
>
> On Aug 1, 2013, at 11:14 AM 8/1/13, Andy Bierman  wrote:
>
>> Hi,
>>
>> Isn't it obvious why humming is flawed and raising hands works?
>> (Analog vs. digital).  A hand is either raised or it isn't.
>> The sum of all hands raised is comparable across tests.
>
> The repeatable test gives *an* answer, but is not necessarily the answer that 
> best reflects the sentiment of those answering the question.
>
> A relatively imprecise thermometer that gives a reading close to the measured 
> temperature is more useful than a digital thermometer that gives a precise 
> but highly inaccurate reading.
>

I disagree.  Whether I raise my hand to ear level, 2 inches above my head,
or as high as I can reach, the chair will still count my raised hand as "1".
If I hum really load (and if everybody hums at a different volume) the
chair cannot possibly know how to quantify that result.

Quantifying the number of raised hands is not a judgement call,


> - Ralph

Andy


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

Re: 6tsch BoF

[Andy Bierman]

Hi,

Isn't it obvious why humming is flawed and raising hands works?
(Analog vs. digital).  A hand is either raised or it isn't.
The sum of all hands raised is comparable across tests.
The sum of the amplitude of all hums is not.


Andy

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

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

[Andy Bierman]

Hi,

On Tue, Jul 16, 2013 at 10:17 AM, Ted Lemon  wrote:
>...
> given the number of graybeards who attend IETF,
> I think paying attention to the problem of excessive sugar in break foods is 
> really important.
>

I'm not supposed to have sugar, so the massive quantities of cookies,
brownies, ice cream, etc. in the breaks are an unwanted distraction.
But that doesn't mean I want celery and carrots instead. :-)
I suggest more cheese and crackers, sandwiches, etc.
and perhaps less cookies.

Andy

Re: IETF registration fee?

[Andy Bierman]

On Wed, Jul 10, 2013 at 4:06 PM, Hector Santos  wrote:
> On 7/10/2013 5:17 PM, Josh Howlett wrote:
>>
>>
 Day passes have nothing to do with it.
>>>
>>>
>>> I disagree. Day passes encourage the notion that it's normal to
>>> parachute into the IETF to attend a single session. I think that the
>>> IETF's strength is that we don't totally compartmentalise work items.
>>
>>
>> I am perplexed that there is, on the one hand, a (valid, IMHO) concern
>> about increasing IETF diversity & participation, when there appears to be
>> an active policy of discouraging potential participants who simply wish to
>> get work done in some specific sessions. Superficially, it would seem that
>> making participation more flexible and affordable might help to improve
>> diversity & participation.
>>
>> Josh.
>
>
>
> +1 Thank you. Well said. I had very little limited time but I wanted to
> blast by Orlando from Miami (by car) and attend just one day, just to meet
> the folks I often have electronic battles with over the years.  But the
> daily cost was a little too much and I certainly didn't want (nor ready) to
> stay an entire week to make it cost effective.  Perhaps it is a minor issue
> to attract local area interest, since that would be the only advantage for a
> daily attendance cost.
>
> It seems to be too much contradictory discussion about diversity. I don't
> have too much confidence anything will be improved.
>

+1
Just because I want to attend all week doesn't mean everybody
else should also want to do the same, or can afford the time and expense.

Back when I was RMONMIB WG Chair, it was difficult to get developers
to attend the IETF.  They were too busy implementing the RFCs to
spend an entire week at the IETF.  They really didn't want to expand
their horizons and attend extra meetings for WGs they didn't follow.
I think a 1-day pass would have helped a little, since one still has to make
travel plans in advance of the final agenda.

It seems to me that a cheap 1 day pass and ultra-cheap 1 day student pass
would encourage local people to attend their first IETF.


> --
> HLS
>

Andy

Re: The Nominating Committee Process: Eligibility

[Andy Bierman]

Hi,

I am strongly opposed to a remote meeting registration process and remote
meeting fees.
This increases the financial bias towards large corporate control of IETF
standards.
I like the IETF because anybody can comment on a draft or write a draft
without
paying fees.

I think there could be several ways to prove one has been recently involved
in the
IETF.  IMO I-D or RFC authorship shows more involvement than just showing up
at an IETF.  People who never read, write or comment on any drafts can be
more nomcom-qualified (by attendance metrics) than somebody who worked on
10 drafts
over the same time span.

Andy


On Thu, Jun 27, 2013 at 6:36 AM, Dave Cridland  wrote:

> On Thu, Jun 27, 2013 at 2:21 PM, Michael Richardson  > wrote:
>
>>
>> Arturo Servin  wrote:
>> > Today it is possible to verify that somebody attended to an IETF
>> > meeting. You have to register, pay and collect your badge. However,
>> in
>> > remote participation we do not have mechanisms to verify that
>> somebody
>> > attended to a session.
>>
>> We need to have registration for remote participation, even if we charge
>> zero.   I believe that perhaps we need to provide some magic token in
>> jabber
>> or in the NoteWell slide, that needs to be used by remote participants to
>> check-in. They have to do that during the meeting itself.
>>
>
> We could require room registration for the XMPP ("Jabber") chatrooms, and
> have remote participants fill in an equivalent of the blue sheet in order
> to join the room.
>
> I'm not sure if the current XMPP implementation supports this, but it will
> work in principle with a number of existing deployed implementations.
>
> (And, note, we no longer have to care about Google Talk interop, which
> makes things easier).
>
> Dave.
>

Re: ietf@ietf.org is a failure

[Andy Bierman]

Hi,

I'm not sure how the desire for IETF Last Call discussions
to be on a dedicated and constrained mailing list in any way
implies that this generalized and unconstrained list is somehow a failure.

Filtering by subject line is unreliable.
For example, please provide a filter that will
not have any false positives or negatives over the
past 20,000 emails on this list. Do we have tools that make sure
no human has altered any subject line inappropriately?
Filtering by mailing list address is much easier and more reliable.


Andy




On Sat, Jun 8, 2013 at 1:20 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 09/06/2013 07:55, Melinda Shore wrote:
> > On 6/8/13 10:09 AM, SM wrote:
> >> As an off-topic comment, there are are alternative ways in making a
> >> decision; the best judgement of the most experienced or IETF Consensus.
> >
> > I don't think it's off-topic.  Consensus (rough or otherwise) requires
> > that at some point people can live with decisions with
> > which they disagree.  To the extent that we've seen recent misbehavior
> > on this list, it's from only one person who's rejecting the consensus
> > and rejecting the process.  It's really annoying but I don't think
> > it's particularly disruptive.  If it becomes disruptive, there's a
> > rarely-used hammer: the PR action.
>
> I agree. Whatever misbehaviour Melinda means hasn't troubled me;
> it must be a user or a thread that I filter to junk.
> Disagreement is fine as long as people in the end understand
> when they're in the rough and not in the consensus.
>
> There are times when this list annoys me too, but it is far from
> a failure IMHO.
>
>Brian
>
>
>

Re: Weekly posting summary for ietf@ietf.org

[Andy Bierman]

On Fri, Jun 7, 2013 at 8:52 AM, Ted Lemon  wrote:

>  On Jun 7, 2013, at 11:48 AM, Andy Bierman  wrote:
>
>  So why not move the signal?
>  Put IETF Last Call mail on last-c...@ietf.org and leave this list for
> everything else.
>
>
> The discussion still has to happen somewhere.   I certainly am not
> restricting my meaningful participation in last calls, but even in that
> case it is important to be restrained and not get into long fruitless
> discussions, which, I am afraid, I am wont to do.
>
>

Some people consider the last call discussions to be signal
and the rest (vast majority) of discussions to be noise.
They would subscribe to a last-call mailing list, but not this one.


Andy

Re: Weekly posting summary for ietf@ietf.org

[Andy Bierman]

On Fri, Jun 7, 2013 at 7:49 AM, Thomas Narten  wrote:

> What the weekly stats really ought to tally up is the readers/postings
> ratio, so that folk would get more direct feedback as to whether what they
> are
> posting is actually being read...
>
> My strong suspicion would be that there is strong negative correlation
> between frequency of posts and actual readers of those posts...
>
> Also, I suspect that many people do not realize that a significant
> chunk of IETF contributers are no longer subscribed to the ietf list
> due to signal to noise ratio concerns...
>
>
So why not move the signal?
Put IETF Last Call mail on last-c...@ietf.org and leave this list for
everything else.

I don't really want people counting their bytes when they are concerned
about
a technical issue in an I-D.  It may take several exchanges for a
disagreement
to be resolved.  Social pressure to stay out of the top-N report could have
a negative impact on last call debates.


Thomas
>
>
Andy

Re: Issues in wider geographic participation

[Andy Bierman]

Hi Jari,

On Mon, May 27, 2013 at 5:15 AM, Jari Arkko  wrote:

> John,
>
> > * People aren't aware the IETF exists, or what it does, or that it has
> > an open participation model
> >
> > * People don't read and write English well enough to be comfortable
> > participating
> >
> > * People are unaccustomed to and perhaps uncomfortable expressing
> > overt disagreement
> >
> > * People don't think they have anything to contribute to an organization
> > that is mostly people from rich countries
> >
> > * People don't have adequate Internet access for mail, or to use the
> > remote participation tools
>
> Thanks for sending out a list of potential issues.
>
> I think there may be one issue missing from the list. At the end of the
> day, what tends to drive people actual, concrete benefit to themselves or
> their organisations. A drive that is so big that it forces you to cross
> language and other barriers and make at least a time investment in
> participation. As an example, the number of Chinese participants has
> increased rapidly in the IETF. Why? We probably didn't suddenly get much
> better at welcoming new people at the IETF, but the new participants felt
> that work on the Internet is important to them personally, and their
> organisations felt that they need to be part of making Internet standards.
> This isn't very surprising, given, for instance, the rise of the Chinese
> technology industry to a very visible role in the world.
>
> So I feel that the issue in many cases is simpler than the ones in the
> list: "What's in it for me"? This obviously has to do with the role of
> vendors in the IETF and the distribution of tech industry in the world. It
> may also have something to do with doing things that are important. I'm
> sure we could be working on topics that are even better aligned to what the
> world needs… if the people who need them were here to tell us :-)
>
>

This is the most important factor and trumps all other combined.
If the standards work is relevant to your business or research then
the probability that you will participate in the IETF goes way up.

I think many people on this list forget how different doing engineering
in the IETF is from engineering for a private enterprise. Tasks that take
1 or 2 months in a private enterprise often take 1 or 2 years (or more!).
Competitors working on a standard have a completely different set
of incentives than employees working on a product, so agreement
on standards is much harder to achieve.

Newbies can have a hard time adjusting to these differences.




> The IETF can't change the distribution of industries in the world, but we
> can, for instance, focus on the vendors that are there or work more on
> topics that are interesting for the operational folks. The latter would be
> a good idea for the IETF, anyway.
>
> > For example, if language and net access is a problem, it might be
> > interesting to set up a remote participation center in B.A. during one
> > of the North American meetings (it's one time zone off from Toronto)
>
> We've been looking at setting up something like that (not for BA
> specifically).
>
> Jari
>
>

Andy

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

[Andy Bierman]

On Fri, May 17, 2013 at 7:29 PM, Keith Moore wrote:

> On 05/17/2013 10:21 PM, Andy Bierman wrote:
>
>>
>> I notice that nowhere on this list is any mention of the charter
>> milestones
>> or dates.  Is the Foo Proto draft due in 14 months or is it 14 months
>> behind
>> schedule?  If the latter, why isn't the Foo WG meeting at the IETF?
>>
>>
> I don't think milestones will be useful unless and until:
>
> (a) they're defined in terms of not only concrete but also meaningful
> goals (e.g. "complete problem definition", "identify affected parties and
> groups representing their interests", "complete outline of initial design",
> but NOT "revise document X");
> (b) we start automatically suspending the activities of groups that fail
> to meet them (no meetings, no new I-Ds accepted, mailing list traffic
> blocked), until such groups are formally rechartered; and
> (c) IESG is reluctant to recharter groups that have repeatedly failed to
> meet milestones, especially if those groups haven't produced evidence of
> significant progress.
>
>
I think we can find some middle ground between "ignore charter milestones
completely"
and "autobot to terminate WGs behind schedule". :-)

Keith
>
>
Andy

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

[Andy Bierman]

On Fri, May 17, 2013 at 6:29 PM, Keith Moore wrote:

> On 05/17/2013 04:36 PM, Yoav Nir wrote:
>
>> On May 17, 2013, at 6:37 PM, Dave Crocker  wrote:
>>
>>  On 5/17/2013 7:01 AM, Keith Moore wrote:
>>>
 But WGs should be able to periodically summarize what they're doing -
 what problem they're trying to solve, what approach they're taking, what
 technologies they're using, what major decisions they've made, what the
 current sticking points seem to be, what problems are as yet unresolved,
 what potential for cross-group and cross-area effects have been
 identified, and what efforts have been made to get the affected parties
 in the loop.   For most groups that summary should be maybe 2-3 pages.
 The ADs should be able to verify that those summaries are accurate and
 reasonably complete, or appoint a trusted WG observer other than the
 chair to review each summary. ADs and other members of the community
 should be able to view those summaries and comment on their accuracy.

>>>
>>> The idea that working groups should be required to issue periodic
>>> project progress reports seems strikingly reasonable and useful.
>>>
>>> This makes the folks who are the most knowledgeable responsible for
>>> assessing their work, and should facilitate public review. Recording the
>>> sequence of reports into the wg datatracker could nicely allow evaluating
>>> progress over time.
>>>
>>> It also, of course, nicely distributes the work.
>>>
>>> d/
>>>
>> "
>> From: WG Chair
>> To: ietf@ietf.org
>> Sunbject: Progress Report - Foo WG
>>
>> There has been zero activity on the FOO list in the last three months
>> (except for that "Fake Conference" message everybody got last month). I've
>> tried emailing the WG document authors twice, but they're not answering my
>> emails.
>>
>> So, the WG has 2 documents: draft-ietf-foo-use-cases-03, and
>> draft-ietf-foo-proto-01.
>>
>> The use case document is just about done, but we haven't really started
>> discussing the proto document. We haven't met in Orlando, and are unlikely
>> to meet in Berlin
>>
>> That's it for this report.
>>
>> Cheers
>>
>> WGC
>>
>> "
>>
>
> Instead of a WG progress report, what I had in mind was a separate report
> for each work item.   The report should briefly describe
>
> 1. The purpose of the work being undertaken
> 2. A description of the work being undertaken (including mention of major
> technologies on which the work is based)
> 3. All known parties and interests likely to be affected by the work
> 4. The current state of the work (what's been done, what hasn't been done)
> 5. Any major issues that have been identified but not resolved
> 6. Pointers to the WG's charter, the datatracker pages for each of the
> current draft document(s) associated with that work item, and any other
> useful material (e.g. open issues list, summaries of design decisions
> already taken and the rationale for each)
>
> A person who is knowledgeable about current Internet protocols should be
> able to read that single document and understand what the WG is doing with
> this particular work item, what state it's in, whether or not it will
> affect that person's are of interest, and where to look for detailed
> information.
>
>
This seems like a good idea, although maybe a bit formal.
IMO, big surprises at the tail end that cause lots of work to
be thrown out are evidence of a management failure.
The IESG and WG chairs should be more proactive wrt/ avoiding
late surprises from ever happening.

I notice that nowhere on this list is any mention of the charter milestones
or dates.  Is the Foo Proto draft due in 14 months or is it 14 months behind
schedule?  If the latter, why isn't the Foo WG meeting at the IETF?



Keith
>
>
Andy

Re: call for ideas: tail-heavy IETF process

[Andy Bierman]

Hi,

The evidence seems to show that the IESG is getting faster
at their job and WGs are getting slower at theirs.  I don't
see any need for "DISCUSS Rules".  All the AD reviews I've
experienced have improved the document, sometimes a lot.
All DISCUSS issues got cleared with reasonable (even good)
solutions.

IMO, there is no question that applying the right expertise at the
appropriate time in the WG draft process would improve the
entire system and avoid surprises during I* Last Call.
The question is the best way to do that.

Andy


On Tue, May 14, 2013 at 4:57 PM, Joel M. Halpern wrote:

> And your bottom line is exactly what te rules say, what I said, what Ted
> said, and what Joe agreed is reasonable.  It also matchesthe practice I
> have seen.  Even the discuss that I had a lot of arguments with did include
> proposals for paths forward.  Sometimes they were ard to understand.
>  That's probably inevitable with all these opinionated humans doing this.
>
> Yours,
> Joel
>
> On 5/14/2013 7:15 PM, Dave Crocker wrote:
>
>> On 5/14/2013 3:46 PM, Andrew Sullivan wrote:
>>
>>  To be fair, for what it's worth as a WG chair I've had the latter
>>> experience at least as often as the former in the use of DISCUSS, and
>>> I've observed some DISCUSSes cleared without any change at all to the
>>> document in question.
>>>
>>
>> We suffer a continuing logic error in the IETF.  We use "sometimes it
>> happens the other way" as if that negates the existence and problem
>> cause by what is being criticized.
>>
>> So, yeah, of course a Discuss /sometimes/ causes a small delay with no
>> changes.  /Sometimes/ ADs use the sledgehammer of the Discuss to ask for
>> a bit of conversation.  That's all irrelevant.
>>
>> What's relevant is the nature of the mechanisms, its capability, and the
>> cost it can and does impose on authors and the working group.
>>
>> When a serious defect is identified, it's entirely worth the cost.
>>
>> When it isn't, it isn't.
>>
>> In all cases, the person imposing the cost has an obligation to
>> facilitate closing it, including making clear the criteria for closing
>> it.  It is unreasonable to have those who must do the work to clear it
>> play a guessing game.
>>
>>

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Andy Bierman]

On Fri, May 10, 2013 at 7:37 AM, Joel M. Halpern wrote:

> I am guessing that the authors intended the addition of the text
> emphasizing that the no-zone typedefs are derived general typedef addresses
> the difference in the patterns.
>
> Is there a YANG rule that says tat if typedef X is derived from typedef Y
> then the string for X must match the pattern for X and the pattern for Y?
>  If so, then my concern below is misplaced.  (The fact that I find the
> vague pattern for the child misleading is not a fault with the document,
> but rather in my head, under that requirement.)
>

Yes. RFC 6020, sec. 9.4.6.
All the patterns are ANDed together.


>
> Yours,
> Joel
>
>

Andy


> On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>>
>> 
>> >.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-netmod-rfc6021-bis-**01
>>  Common YANG Data Types
>> Reviewer: Joel M. Halpern
>> Review Date: 19-April-2013
>> IETF LC End Date: 1-May-2013
>> IESG Telechat date: N/A
>>
>> Summary: This document is nearly ready for publication as a Standards
>> Track RFC
>>
>> Major issues:
>>  (The following may well be a non-issue.)
>>  In the revision of the ietf-inet-types, the patterns for the new
>> ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
>> from the ipv4-address and ipv6-address patterns.  The new
>> ipv4-address-no-zone allows any sequence of decimal digits an periods,
>> while the original was carefully defined as dotted quads of 0..255.
>> Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
>> digits and colons.  The original patterns were very careful to match
>> rules for validity.  Is there a reason for the change.
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>> __**_
>> Gen-art mailing list
>> gen-...@ietf.org
>> https://www.ietf.org/mailman/**listinfo/gen-art
>>
>>

Re: call for ideas: tail-heavy IETF process

[Andy Bierman]

..

> WG chairs might like to comment, but I suspect that one lunchtime training
> session every four months does not constitute proactive management.
>
>
+1 !!!

It works on down the line too.
WG Chairs meeting with I-D editors once every 4 months isn't so great
either.

If the total time has gone up 100 days, and the IESG time has gone down
100 days, then clearly the WG process is the main problem.

I'd like to see some stats on average delta between revisions of an I-D,
with some metric for the number of changes per revision.  I suspect
it would show way too many drafts that have a few edits once every
4 months. (One of mine right now even ;-)

The WG Chairs need more training on how to avoid the "slow tweak mode"
problem. The ADs need to manage their WG chairs so this doesn't happen.


Adrian
>
>
Andy

Re: call for ideas: tail-heavy IETF process

[Andy Bierman]

On Wed, May 1, 2013 at 9:33 AM, Michael Richardson wrote:

> <#part sign=pgpmime>
>
> > "Jari" == Jari Arkko  writes:
> Jari> I wrote a blog article about how we do a fairly significant
> Jari> amount of reviews and changes in the late stages of the IETF
> Jari> process. Next week the IESG will be having a retreat in
> Jari> Dublin, Ireland. As we brought this topic to our agenda, Pete
> Jari> and I wanted to raise the issue here and call for feedback &
> Jari> ideas for improving the situation with all of you.
>
> Jari> http://www.ietf.org/blog/2013/05/balancing-the-process/
>
> I'll repeat what has been said repeatedly in the newtrk and related
> discussions.  The step from ID to "RFC" is too large because we are
> essentially always aiming for "STD" rather than "PS".
>
>

I don't think this helps.  We want the highest quality documents
possible for developers to translate into implementations.

IMO, the answer is to identify cross-area issues early,
and more importantly, get early cross-area reviewers to help
avoid bad decisions that won't make it through IESG review.
Maybe a cross-area expert needs to join a design team
for awhile to make sure good decisions are made.

The ADs need to make sure these early reviews get
staffed and completed.  Maybe additional people
(directorate?) helps manage this process.


Andy



If we are unwilling to bring "RFC" back to a place were it does not
> equal STD, then we need to create a new category of document which
> amounts to "fully baked ID".  Things like IANA allocations could occur
> at that point.
>
>
> In the days of dot-boom it was not unusual to see widespread
> implementation very early in the ID process and even interop and
> experimental deployment.   While this still occurs for quite a number of
> things (and sometimes it's a problem that the ID can not be changed as a
> result), there is an equal amount of "wait for the RFC to come out".
>
>
> I believe that we probably need to simply do less.
> Or perhaps we've reached the n^2 overhead problem, and since resources
> are less(%), if we can't increase resources allocated to overhead, then
> it's time to reduce n:  the IETF should fork and/or shard somehow.
>
>
> (%)-it's not just about $$ invested, it's also, I think, that after
> many years of caffeine and sugar, many of us are simply
> immune to their effects, and/or have given them up.
>
>
> (2)-by adding an intermediate step in the "ID" process, I haven't
> removed the "heavy" part of the process, I've just redefined the
> process so that it's no longer at the "tail" of the process.
> This is, I admit, akin to adjusting the definition of unemployment.
>
> But, we can all agree when an ID is baked enough for the WG to
> consider it deployable, then we will actually get to the "running
> code" part sooner, which frankly is the only real way to get
> real experience.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
>[
>
>
>
>

Re: IETF Diversity Question on Berlin Registration?

[Andy Bierman]

On Wed, Apr 17, 2013 at 7:52 AM, Eliot Lear  wrote:
> Dan,
>
> On 4/16/13 2:00 AM, Dan Harkins wrote:
>
>> Under the belief of "garbage in, garbage out", I tend to lie on these
>> sorts of repugnant questions. I invite others to join me. The more
>> suspect the quality of the data, the less value it has. Dan.
>
> Please don't.  We are trying to understand who we are.  Is that SO
> unreasonable?
>

I don't object to filling out forms, and I would certainly answer honestly.
Who is "we"?  Just people who go to the Berlin IETF?
   - does it include remote participants via Jabber or other tools
   - does it include people who participate only on WG mailing lists?

The only bias I see is that it takes a lot of employer backing
and funding to participate in the IESG.  It is therefore the
companies that sponsor these participants have the most influence of all
over the selection process.

Hold another IETF in San Jose or San Francisco and I bet we get
way more balanced data than a site that requires a lot of travel,
especially since we have day passes now.

> Eliot

Andy

Re: Purpose of IESG Review

[Andy Bierman]

On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred)  wrote:
> In my opinion, some individual ADs seem to, from their behavior, feel that 
> they have not done their jobs unless they have raised a "discuss". The one 
> that took the cake for me personally was a "discuss" raised by a particular 
> AD (who shall remain nameless) that in essence wondered what he should raise 
> a "discuss" about in my document. There were a couple of errors in that; he 
> told me later that what he had done was opened the comment tool and typed 
> that question, and subsequently accidentally hit the equivalent of "send" - 
> the question wasn't intended to go out. But the question itself is telling: 
> the issue was not "does the document meet the requirements of BCP 9", it was 
> "what comment shall I raise"?
>
> Also, in my opinion, IESG review that raises a certain number of issues 
> should not result in the document sitting in the IESG's queue for a few 
> months while the authors go back and forth with the AD or the GEN-ART 
> reviewer pounding the document into someone's idea of "shape" without working 
> group involvement. I personally would prefer that simple matters get sorted 
> out between the ADs and the author, but complex changes or additional content 
> requested by the AD should result in the document being sent back to the 
> working group.

Many of us can change the acronyms and describe a similar experience.
I would say "We don't have the authority to make that decision
without asking the WG" a lot.

But this is a 2nd order problem.
The real issue is the way the IESG manages WGs.
Good management doesn't fall out for free.
It is yet another continuous integration progress.
The IESG is the overworked bottleneck in the system
and the review process is the main reason.

The ADs that own a WG should be the main IESG members
that get involved at the details for any possible issue,
and hopefully make these comments/changes as early
in the WG process as possible.

During IESG review, the ADs from other areas should
restrict their comments to issues related to their area.
The final review should avoid changes made
which are feature redesigns or feature enhancements,
and limit changes to bug fixes only.


Andy

Re: [OPSAWG] Basic ietf process question ...

[Andy Bierman]

On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan)  wrote:
> Hi,
>
> The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
> concerning the revision of RFC1052 and discussing a new architecture for
> management protocols.
>
>
> My personal take is that no one protocol, or one data modeling language
> can match the operational requirements to configure and manage the wide
> and wider range of hosts, routers and other network devices that are
> used to implement IP networks and protocols. We should be talking
> nowadays about a toolset rather than one tool that fits all. However,
> this is a discussion that just starts.

NMS developers need to spend too many resources on translating
naming and other data-modeling specific details so they can be
usable within the application.  So if 1 data modeling language
is not used, then deterministic, loss-less, round-trip translation
between data modeling languages is needed.  Multiple
protocols are not the problem -- incompatible data from multiple
protocols is the problem.

>
> Regards,
>
> Dan
>

Andy

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

Re: Future Handling of Blue Sheets

[Andy Bierman]

On 04/23/2012 10:13 AM, Michael StJohns wrote:



At 12:22 PM 4/23/2012, Melinda Shore wrote:

On 4/23/12 6:58 AM, Scott O Bradner wrote:

see rfc 2418 - they are to keep a record as who is taking part in a WG's 
activities
keeping track of attendees is a basic part of any standards development 
organization's process


The tension here appears to be between transparency of process and an
individual right to privacy.  I think that the IETF has a considerable
stake in the former, not just because of the frequency with which some
little pisher or other threatens to sue over what they perceive to be
trust/collusion issues, but because openness is an IETF institutional
value.  I think it should continue to be.  I understand the privacy
issues (although I won't necessary lump them as an instance of revealing
PII) but tend to think that the information being revealed is pretty
sparse and the privacy concerns here probably aren't substantial enough
to counterbalance the organizational interest in keeping processes as
open as possible.

Melinda



And to put a further point on it - the last sentence of the "NOTE WELL" notice 
(http://www.ietf.org/about/note-well.html) that applies to each and every IETF meeting and working 
group session and IETF activity is very clear that written, audio and video records can and will be 
kept.  A person attending an IETF meeting has no reasonable expectation of privacy for those things 
we define as "IETF activities".

So if someone demands "privacy", the price is non-participation in the IETF.



Not exactly -- the NOTE WELL applies to contributions.
Is just showing up and observing the meeting considered a contribution?

Personally, I don't think the blue sheets should even be filled out,
let alone published.  The WG chairs can convey the meeting room size 
requirements
without passing around clipboards and (hopefully) everybody writing down their 
name.

There is no correlation between the blue sheets and IETF contributions.
I don't see what purpose they serve anymore.


Mike




Andy

Re: Trade show at IETF

[Andy Bierman]

On 03/16/2012 01:35 PM, Sam Hartman wrote:

"IAOC" == IAOC Chair  writes:


 IAOC>QUESTION: What do you think about doing a Beer and Gear
 IAOC>  style of event on an evening that does not conflict with other
 IAOC>  IETF activities?

I think that hallway conversations, private meetings and other
activities that people have already filled Sunday after the
reception,Monday, Thursday and Friday with are more important.  I think
this would make an already crowded event more crowded and while it might
be useful would detract from other more important uses of the time.
So, I am not generally supportive of this idea.




NANOG has network operators as the audience but the IETF has a more mixed 
audience.
I support ideas to raise money, and I would go to this event, out of curiosity.
I'm not looking to buy any networking equipment though.

I would actually like more lunch-time lectures and discussions.
(Maybe M, T, and Th so WG Chairs lunch on W does not conflict).
Perhaps vendors or researchers would be willing to make a donation
to get one of those lunch slots?


Andy

Re: primary Paris hotel booking

[Andy Bierman]

On 01/03/2012 08:52 AM, George, Wes wrote:

Happy New Year, it's time for our triannual hotel complaint thread.
I hate to do it, but I think that there are people who haven't looked at this 
yet, and I'm hoping that we can perhaps rectify it before the majority of folks 
try to book:

  "Instructions for making reservations at Hotel Concorde:
Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 
00 50 79 or email it to cmas...@concorde-hotels.com"


I crossed my fingers and clicked 'send' of the PDF with my credit card number 
in it.
I didn't pay enough attention to the no-refund policy.  :-(

I emailed my reservation on 12/22 and got a confirmation email on 12/26.
So far, my credit card has not been charged anything.

I think there should always be a full-refund cut-off date for the IETF hotel, 
even if
it is 2 months in advance.  I thought the cut-off was 15 days, but that is just
for 2 more nights billed in advance, not the first night.


Andy

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

RE: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments

[Andy Bierman]

Hi,

The  was removed from the diagram to make room for
the notification stuff on the right.  It does not mean that
 was removed from the protocol.  The box just showed
2 of the many operations, now only 1.


Andy


-Original Message-
From: Tina Tsou [mailto:t...@huawei.com] 
Sent: Thursday, March 03, 2011 10:31 AM
To: secdir-secret...@mit.edu; sec...@ietf.org; 'The IESG'; ietf@ietf.org
Cc: draft-ietf-netconf-4741...@tools.ietf.org
Subject: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments

Hi,
I rechecked draft-ietf-netconf-4741bis-09, only one more comment:

Why  is deleted from figure 1 compared with RFC4741? 
RFC4741:
  Layer  Example 
 +-+  +-+ 
 (4) |   Content   |  | Configuration data  | 
 +-+  +-+ 
|   | 
 +-+  +-+ 
 (3) | Operations  |  | ,  | 
 +-+  +-+ 
|   | 
 +-+  +-+ 
 (2) | RPC |  |,| 
 +-+  +-+ 
|   | 
 +-+  +-+ 
 (1) |  Transport  |  |   BEEP, SSH, SSL, console   | 
 |   Protocol  |  | | 
 +-+  +-+ 

RFC4741bis: 
Layer Example 
   +-+  +-+  ++ 
   (4) |   Content   |  |  Configuration  |  |  Notification  | 
   | |  |  data   |  |  data  | 
   +-+  +-+  ++ 
  |   |  | 
   +-+  +-+  | 
   (3) | Operations  |  ||  | 
   | |  | |  | 
   +-+  +-+  | 
  |   |  | 
   +-+  +-+  ++ 
   (2) |  Messages   |  | ,  |  |  | 
   | |  |  |  || 
   +-+  +-+  ++ 
  |   |  | 
   +-+  +-+ 
   (1) |   Secure|  |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | 
   | Transports  |  | | 
   +-+  +-+


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-Original Message-
From: secdir-boun...@ietf.org [mailto:secdir-boun...@ietf.org] On Behalf Of
Samuel Weiler
Sent: Saturday, February 26, 2011 3:57 AM
To: sec...@ietf.org
Subject: [secdir] Assignments

Review instructions and related resources are at:
 http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Hilarie Orman is next in the rotation.

For telechat 2011-03-03

Reviewer LC end Draft
Rob AusteinT 2011-02-16 draft-ietf-netconf-rfc4742bis-07
Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05
Donald EastlakeT 2011-03-01 draft-ietf-6lowpan-usecases-09
Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09
Love Hornquist-Astrand T 2011-02-21
draft-ietf-v6ops-v6-in-mobile-networks-03
Russ Mundy T 2011-02-17 draft-ietf-speermint-voipthreats-07
Tina TSOU  TR2011-02-07 draft-ietf-netconf-4741bis-09
Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05
Sam Weiler T 2011-02-16 draft-ietf-hokey-ldn-discovery-06
Glen Zorn  T 2011-02-10 draft-ietf-shim6-multihome-shim-api-16


For telechat 2011-03-17

Jeffrey Hutzelman  T 2011-03-09 draft-zhu-mobility-survey-03
Catherine Meadows  T 2011-03-09 draft-ietf-ancp-protocol-15
Kathleen Moriarty  T 2011-03-11
draft-ietf-intarea-server-logging-recommendations-03
Magnus Nystrom T 2011-02-23
draft-meadors-multiple-attachments-ediint-10
Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05
Carl Wallace   TR2011-02-22 draft-herzog-setkey-03


For telechat 2011-04-14

Sandy Murphy   T 2011-03-23 draft-kanno-tls-camellia-00

Last calls and special requests:

Dave Cridland2011-02-21 draft-ietf-sidr-arch-12
Alan DeKok   2011-02-23 draft-ietf-isis-reg-purge-00
Shawn Emery  2011-02-21 draft-ietf-ecrit-phonebcp-16
Sam Hartman 

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman]

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman  
>>>>>> said:
> 
> AB> Oherwise the agent would deadlock.
> AB> discard-changes does not affect the running configuration.
> 
> No, but it does affect the other users notion of changes.  You should
> never be allowed to discard changes that another user has made.
> 

this assumes you have an access control model in mind.
I do too -- they aren't the same.
Without any standards for this, neither of us are wrong.


> AB> It just resets the scratchpad database.
> AB> Why bother applying the ACLs before the edit operation
> AB> is attempted for real?
> 
> user 1: add new important policy configuration
> user 2: discard-changes
> user 1: commit
> 
> Granted, user 1 should be using locks of some kind.
> 

what is the NETCONF 'add new' operation?
step 1 is very unclear.


> To undo changes it's rather important that someone with proper
> authorization to the everything changed (IE, an admin) performs the
> discard.
> 
> Or are you suggesting that one shouldn't ever have access control
> applied to the candidate store in the first place?  (I hope not).
> 

I apply it to the candidate and to running,
except discard-changes, otherwise the agent would deadlock
often and that would be counter-productive
to network operations.

When you start with an awful design premises like
locking should be optional to use, then you might
end up with messy code.  Nothing new there.


> AB> Requiring small embedded devices to serve as robust
> AB> database engines may be more expensive than
> AB> the rest of the code combined.  We are coming from
> AB> an operational environment based on humans using the CLI,
> AB> which has no locking at all.  The globally locked
> AB> candidate "edit, validate, and commit" model
> AB> is way better than anything we ever had in SNMP or CLI.
> 
> If you look at history of operating just about anything, after it gets
> to a point where multiple operators need to scale things up you'll find
> that eventually stuff gets put into a multi-user revision database type
> system.  We are far beyond the point where operators are editing single
> flat-files using "vi" and hitting "save" without any form of revision
> control.  After that point, then went to locking version control systems
> (sccs?  I'm forgetting the early version-control system names).  Then
> people realized that caused huge headaches because the global file
> locking, although it prevented some types of problems, caused a bunch of
> other problems.  Eventually more modern version control systems were
> developed that allowed people to simultaneously edit things and only
> get bothered when conflicts happen.  This was a huge win, ask anyone who
> works with version control systems.
> 
> But now, in this space, we're going back to the older methodologies of
> editing a single file and hoping that two people don't conflict (with or
> without a lock).
> 

again -- when locking is optional to use, the database
is never going to be very good.


> 
> I've said this before, but I'll repeat it now: netconf, from a
> protocol-operation point of view, is designed to work in a
> single-operator type environment.  The instant you add multiple-users
> with or without different roles all these problems come up.  This is
> actually just fine, but it needs to either:
> 
> 1) be fixed so that these problems go away.
> 2) stop being advertised as a multi-operator type solution.
> 

I disagree.
The partial-lock feature is not needed in every environment.
NETCONF supports the SQL-like model (write directly to
the persistent datastore) and that is good enough.
Why does the scratchpad model need to be per-session?
That is nice-to-have, but not important.


> I think "being fixed" is a great long term goal.  But for right now, I'd
> suggest we simple say "this is version 1 at the moment and it is
> currently designed for use by single-operator systems".
> 
> (And it doesn't prevent an external version-control system for being the
> master and pushing the config down.  It just doesn't work on the device
> itself).

Andy

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

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman]

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman  
>>>>>> said:
> 
> AB> discard-changes only works because authorization is ignored,
> AB> otherwise the agent would be deadlocked.
> 
> Huh  why would discard-changes be authorization ignorant???  That's
> just as unsafe (unless you're only discarding your own changes).
> 

Oherwise the agent would deadlock.
discard-changes does not affect the running configuration.
It just resets the scratchpad database.
Why bother applying the ACLs before the edit operation
is attempted for real?

> AB> Only the global lock operation defined in RFC 4741
> AB> can prevent this problem.
> 
> The global lock has different issues.
> 
> The problem isn't with the locking.  Locking, and partial locking are
> good.  It's with the global-level commit operation.

Requiring small embedded devices to serve as robust
database engines may be more expensive than
the rest of the code combined.  We are coming from
an operational environment based on humans using the CLI,
which has no locking at all.  The globally locked
candidate "edit, validate, and commit" model
is way better than anything we ever had in SNMP or CLI.

If concurrent edits instead of serialized edits are needed,
then the :writable-running + :partial-lock capabilities
support that.



Andy


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

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman]

Stephen Hanna wrote:
> Thanks to Dan and Bert for answering my question.
> If most NETCONF implementations authenticate users
> and implement some form of authorization scheme,
> there should be no problem with including text
> in draft-ietf-netconf-partial-lock-09.txt that
> says "NETCONF servers that implement partial
> locks MUST ensure that only an authenticated
> and authorized user can request a partial lock."
> Even a server that implements authentication but
> does not implement fine-grained authorization
> would meet this requirement. It would just be
> saying that all authenticated users are fully
> authorized to perform any operation on the server.
> 
> Are there any concerns with this proposal?
> If so, please explain.
> 

The partial-lock operation does not work on the candidate
database, yet the draft insists that this database is supported.
It also says it works on the startup database, yet there
is no way to edit this database, so why does it need
to be partially locked?

There is a global commit operation issued by a session.
That session must be authorized to make all the changes
to the running config that are contained in the candidate
(all-or-nothing).

The partial-lock design does not really have any affect
on the candidate -- using it is just as ineffective as
not using any locking at all.  So it is subject to
the 'candidate-deadlock' first described by Wes Hardaker:

Let's say there is a simple config to edit:

  
 3
 fred
  

Let's say user A is authorized to write /foo and
user B is authorized to write /bar.

1) user A does partial-lock(target='candidate', data='/foo')
2) user B skips the lock and just edits the /bar leaf directly
   in the candidate database (even if user B took out a partial
   lock on /bar, the result would be the same)

HALT:

  User A is not authorized to issue commit
  User B is not authorized to issue commit
  The database is wedged until somebody issues a discard-changes.
  discard-changes only works because authorization is ignored,
  otherwise the agent would be deadlocked.

Only the global lock operation defined in RFC 4741
can prevent this problem.


> Thanks,
> 
> Steve

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

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Andy Bierman]

Joel M. Halpern wrote:
To put it differently, the OPS area has as much right to propose their 
requirements as any other area (Transport Congestion, Security, ...) 
has.  And generally, the community has listened to such requests and 
gone along with them.


Yes, we have produced a bit of a problem that our initial standards now 
have a quality bar comparable with completed work.  But we shouldn't 
suddenly pick on OPS for that.  If we are going to address that problem, 
it ought to be in a coherent fashion that discusses how we deal with all 
the legitimate requirements, including the fact that stuff has to be 
operable.




I agree, and I also agree with Randy about the lack of
standardized NETCONF content.  It is a clear indication
that the vendors do not want any standardized configuration
content.  Every time 'content' has come up for charter consideration,
the consensus has been to work on something else instead.

But the NETCONF/YANG pieces are coming together, and it will
allow WGs much more power and flexibility than SNMP/SMIv2
to define management interfaces which fit better with
the native CLI than anything the IETF has had before.

That is about as far as OPS-NM area can go.
If a protocol WG do not want to define a
standard configuration interface, then it
does not matter how well SNMP or NETCONF supports
this sort of work.

(One might question whether using the same NM standardization
methodology for 20 years and achieving consistently pathetic
results means the methodology itself needs to be changed,
not just the technology.)


This does not mean we have to simply accept what they (OSP) say.  But it 
does mean we should give it a fair review, looking at the details, 
rather than objecting on principle.


Yours,
Joel M. Halpern



Andy

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

Re: Running Code

[Andy Bierman]

Peter Saint-Andre wrote:

On 3/3/09 9:08 PM, Masataka Ohta wrote:

Andy Bierman wrote:


Since the goal of our work is to produce specifications
that will allow multiple independent implementations to
inter-operate successfully,

How can you define successful interoperation of implementations?




You gather implementation reports.
You conduct interoperability tests and bake-offs.
This used to happen a lot more, back when advancing
to Draft or Full Standard was considered important.



IMHO you define it by "running code" -- that is, code which is used to
run a functioning communications network. For me the canonical example
is the medium we're using right now: email. In general (there are always
exceptions!), you don't know or care what email clients people use, what
email servers they use, whether they retrieve their email using POP or
IMAP, etc. It just works, at least for the core use cases. And I think
that's why running code (not just compiling code or functioning code,
but a working network) is so important.

Peter



Andy

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

Re: Running Code

[Andy Bierman]

Masataka Ohta wrote:

Hallam-Baker, Phillip wrote:


I don't see the value of running code quite as others do.


I agree. It was valuable in good old days, when implmenting a protocol
was purely voluntary with no budget.

Existence of multiple independent implementations, then, meant the
protocol was widely accepted by the society.

However, after the overly introduction of standardization engineering
to IETF, people satisfy requirements merely because they are required.

So, existence of required running code does not mean much.


I disagree.
It means the specification is implementable.

Since the goal of our work is to produce specifications
that will allow multiple independent implementations to
inter-operate successfully, I can think of no more valuable
review input towards this goal than comments from implementers.

I think adequate procedures exist for gathering implementation
experience for the IESG to evaluate protocol interoperability.




Masataka Ohta


Andy

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

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

[Andy Bierman]

Eric Rescorla wrote:

At Fri, 18 Jul 2008 11:41:15 +0200,
Eliot Lear wrote:

Maybe it's just me, but...



(Fanning the flames...)

I do not understood why WGs are forbidden from conducting
interim or other official extended technical f2f meetings
before, during, or after, an IETF meeting.

Consider the possibility that some participants are focusing
on the charter of 1 or 2 WGs, and perhaps even writing code (!)
in addition to I-Ds.  These people are not too tired from
attending 17 status meetings all week.  These people do not want
to devote an entire week to a few meetings.

The time and cost involved in getting all/most of the principal
technical contributors in the same building for a few days far out-weighs
any fatigue factor cost.

I don't think the IETF meeting fee should cover WG interim meetings,
and I am not convinced there is a big demand for Friday afternoon
WG slots, but if there is a meeting slot shortage, then adding to Friday
is probably the easiest solution.


I oppose this experiment.  I already donate to my employer a significant 
amount of travel time on weekends without wanting to add to it.  Flight 
schedules are tightening, thanks to the cost of fuel, which means that 
having sessions on Friday at all poses a problem now, if I want to get 
back by Saturday.  Having afternoon sessions would put a nail in that 
coffin.


I haven't decided whether I agree with Eliot entirely, but I think
he raises some good points here. I would add two more:

1. I've attended IETFs where there was a meeting on Friday all day
(e.g., the P2PSIP Ad Hoc at IETF 64) and it seemed to me that people
were pretty wiped at that point, so even though they felt that
they had to show up, I'm not sure much got done.





2. People's ability to meet tends to expand to fill out the available
meeting time. 


With these two points in mind, It would be nice to have some metric of
success that's more than just people showing up to the
meetings. Unfortunately, I don't have such a metric. :(



I propose two alternative experiments:

1.  Required agendas and Approval

No session can be approved without a posted agenda.  Many agendas are 
late, which makes it difficult for people to know where they have to be 
and when.


I completely agree with this. Before each IETF I attend I use automated
tools (http://tools.ietf.org/tools/getdrafts/)
to suck down each draft on the agenda and I regularly find 
a large fraction of WGs with missing agendas. As of today, the following

WGs have no agenda:

  softwire, v6ops, mip4, dime, l3vpn, idnabis, l2vpn, ntp, savi, rtgwg,
  ecrit, capwap, radext, opsawg, rtgarea, pkix, opsec, isis, keyprov,
  vcarddav, netmod, pce, saag, grow, autoconf

It's also not just an issue of knowing where to be and when but of
getting prepared. It helps to know in advance which drafts you need
to read.

-Ekr




Andy

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Andy Bierman]

David Harrington wrote:
> 

Here are my reasons why I support the charter, which align with yours:

There are multiple types of users for data models.
The operators and reviewers care about the semantic model
much more than the syntactic mapping.  Ease of use and stability
have proven to be the most important factors for NM data models.

YANG provides enough semantic modeling to be useful for the
NM problem at hand, and since it will be owned by the IETF,
the complexity and stability will also be controllable by the IETF.

By decoupling the syntactic mapping from the semantic model,
the specific mapping rules can change over time as W3C standards
continue to evolve, without impacting any installed base of
data models.  Last year XSD was the only thing.  Now we seem to be
dropping XSD and adopting DSDL instead.  I am not convinced XSD is dead,
or the DSDL will be the final answer either.  But if the YANG
language stays stable, I don't care.


Andy

> 
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>> Behalf Of Eric Rescorla
> 
>>> I propose that you list (again) your (technical) objections
>>> to the the current proposal.
>> Sure. Based on my knowledge of modelling/protocol description
>> languages, the techniques that Rohan described based on RNG and
>> Schematron seemed to me quite adequate to get the job done and the
>> relatively large baggage introduced by defining another language
>> (YANG) which is then translated into them seems wholly unnecessary.
>>
>> I appreciate that some people believe that YANG is more expressive
> and
>> better suited for this particular purpose, but I didn't see any
> really
>> convincing arguments of that (I certainly don't find the arguments
> in
>> F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know
> of
>> the complexity of designing such languages, and of their ultimate
>> limitations and pitfalls, this seems like a bad technical tradeoff.
> 
> The people who believe that YANG is more expressive and better suited
> for this poarticular purpose include contributors to the design of
> SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING
> information and data modeling language,  contributors to the SMIng WG
> which worked on developing a proposed SMIv3 to converge the SMIv2
> standard and the SPPI data modeling language standard and the NMRG
> SMING approach, and engineers who have multiple independent
> implementations of running code for Netconf data modeling. I respect
> their experience and combined knowledge of the complexity of designing
> such languages. 
> 
> I also respect operators' knowledge of the complexity of using such
> languages to actually manage networks. The NM community has been
> working to resolve the problem of the unsuitability of the IETF's
> SNMP-only approach to configuration for many years, and the NM
> comunity has deliberately sought out operators for feedback about what
> does and what doesn't work well for them in configuration data
> modeling.
> 
> One of the major problems of designing a language for data modeling is
> that there are many different constituencies with very different
> requirements for a configuration language, which change over time, as
> can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous
> number of potential tradeoffs to make a general-purpose language meet
> "everybody's" needs. 
> 
> In RFC4101 "Writing Protocol Models", you argue that "reviewers have
> only limited amounts of time" and 
>   "most documents fail
>to present an architectural model for how the protocol operates,
>opting instead to simply describe the protocol and let the reviewer
>figure it out.
> 
>This is acceptable when documenting a protocol for implementors,
>because they need to understand the protocol in any case; but it
>dramatically increases the strain on reviewers.  Reviewers need to
>get the big picture of the system and then focus on particular
>points.  They simply do not have time to give the entire document
> the
>attention an implementor would."
> 
> 
> 
> The NM comunity sought out multiple operator communities, and came to
> a similar conclusion. Operators need to "review" data model
> specifications, and quickly understand the model, often while in the
> middle of fire-fighting. To help address the need to quickly
> understand the model, the MIB Doctors have developed guidelines and
> templates for desecribing the data model in surrounding text. 
> 
> In practice, however, MIB modules are frequently distributed without
> the surrounding document text, and operators responding to network
> problems don't have time to find the right document and read it to
> understand the model. As a result, the NM community concluded that
> data models themselves need to be human readable. MIB modules, for
> example, are read by agent implementers, application implementers,
> operators, and applicatuon users (e.g., when MI

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Andy Bierman]

Harald Alvestrand wrote:
> Eric Rescorla wrote:
>> At Tue, 22 Apr 2008 19:17:47 -0600,
>> Randy Presuhn wrote:
>>   
>>> Our ADs worked very hard to prevent us from talking about technology
>>> choices at the CANMOD BOF.  Our original proposal for consensus
>>> hums included getting a of sense of preferences among the various
>>> proposals.  We were told we could *not* ask these questions, for fear
>>> of upsetting Eric Rescorla. 
>>> 
>> Well, it's certainly true that the terms--agreed to by the IESG and
>> the IAB--on which the BOF were held were that there not be a beauty
>> contest at the BOF but that there first be a showing that there was
>> consensus to do work in this area at all. I'm certainly willing to cop
>> to being one of the people who argued for that, but I was far
>> from the only one. If you want to blame me for that, go ahead.
>>
>> In any case, now that consensus to do *something* has been 
>> established it is the appropriate time to have discussion on 
>> the technology. I certainly never imagined that just because
>> there weren't hums taken in PHL that that meant no hums would
>> ever be taken.
> It's been a month since PHL.
> 
> The IETF's supposed to be able to work on mailing lists between 
> meetings, including being able to work when no WG exists - which of 
> course means working on mailing lists that are not WG lists.
>

Agreed -- this also means that the 'technical approach' straw poll
that did not occur in the CANMOD BoF is not really that important,
since final consensus needs to be confirmed on a designated mailing list.

> I congratulate the participants who worked on the charter on managing to 
> have the discussion and come to consensus on an approach. I think it's 
> up to Eric to demonstrate to the IESG that there's support in the 
> community for disagreeing with the consensus of the discussing participants.

+1

15 person (large!) design team.  1000s of emails.  Done in a month.
This is more effort than most WGs can muster.

> 
>  Harald

Andy

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Andy Bierman]

Randy Presuhn wrote:
> Hi -
> 
>> From: "Eric Rescorla" <[EMAIL PROTECTED]>
>> To: ; <[EMAIL PROTECTED]>
>> Sent: Tuesday, April 22, 2008 10:10 AM
>> Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
> ...
>> Accordingly, if this WG is to be formed, the entire section (and
>> corresponding milestones) which specifies the technology needs to be
>> removed. Rather, the first work item should be to select a technical
>> approach.
> ...
> 
> I think the simplest answer would be to simply publish the work that's already
> been done and not bother with the IETF.  There is simply no value in wasting
> electrons on battles like this.  Sure, some opportunities for technological
> refinement and building a stronger community consensus migh tbe lost, but
> that might be a small price to pay in comparison to the time and energy
> required for all this pointless hoop-jumping.  Particularly since the 
> proposed/
> draft/standard distinction has become so meaningless, it makes more
> sense to just publish the spec and ignore the peanut gallery.
> 

This 'simple' approach doesn't move standardized network configuration
along at all, so it is not my first choice.

IMO, there is strong community consensus for the charter as it
is currently written.  There are several technical approaches,
such as 'continue to write data models in XSD' which are
technically viable, but have no community consensus at all.

I don't think a formal WG process is needed to determine that
the strongest consensus exists for the approach currently outlined
in the charter.  The 15 people on the design team represented
a wide cross section of those actually interested in this work.
I am among the 10 - 15 people who were not involved in the design team,
but agree with the charter.  That seems like a lot of consensus
for this technical approach.



> Randy

Andy

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Andy Bierman]

Eric Rescorla wrote:
> I object to the formation of this WG with this charter.
> 
> While there was a clear sense during the BOF that there was interest
> in forming a WG, there was absolutely no consensus on technical
> direction. Rather, a number of proposals were presented, but no
> strawpoll, hum, or sense of the room was taken, nor, as far as I can
> determine, has there been any such consensus call been taken on any
> list I'm aware of. This wasn't an accident--the BOF was explicitly
> intended only to determine whether some work in this area should
> proceed, not to select a technical approach.
> 
> I understand that an approach like this was proposed in the OPSAREA
> meeting by Chris Newman and then that there was a breakout meeting
> where it was discussed further. The minutes don't record any consensus
> call on this combined direction (only strawpolls on the individual
> proposals), and even if such a consensus call had been held, the
> OPSAREA meeting would not be the appropriate place for it: this
> discussion needs to happen in either the BOF (to allow cross-area
> review) or in the designated WG, when it is formed. 
>


I believe there was consensus in the CANMOD BoF that
the requirements were sufficiently understood, and
the purpose of that BoF had been fulfilled.

After the CANMOD BoF, a 15 person design team was formed,
which reached consensus on a technical approach, embodied
in the charter text.  There was also unanimous agreement
on the charter, outside the design team (on the NGO mailing list).

> Accordingly, if this WG is to be formed, the entire section (and
> corresponding milestones) which specifies the technology needs to be
> removed. Rather, the first work item should be to select a technical
> approach.

I thought the charter text did specify a technical approach,
which is to utilize YANG as a high-level DML and map YANG
constructs to DSDL and XSD.

Can you explain this work item further?


> 
> -Ekr


Andy


> 
>> NETCONF Data Modeling Language (netmod)
>> 
>> Last modified: 2008-04-10
>>
>> Current Status: Proposed Working Group
>>
>> Chair(s): 
>>
>> TBD
>>
>> Operations and Management Area Director(s):
>> Dan Romascanu 
>> Ronald Bonica rbonica at juniper.net
>>
>> Mailing Lists:
>>
>> General Discussion: ngo at ietf.org
>>
>> Description:
>>
>> The NETCONF Working Group has completed a base protocol to be
>> used for configuration management.  However, the NETCONF protocol
>> does not include a standard content layer.  The specifications do
>> not include a modeling language or accompanying rules that can be
>> used to model the management information that is to be configured
>> using NETCONF. This has resulted in inconsistent syntax and
>> interoperability problems. The purpose of NETMOD is to support
>> the ongoing development of IETF and vendor-defined data models
>> for NETCONF.
>>
>> NETMOD's requirements are drawn from the RCDML requirements draft
>> (draft-presuhn-rcdml) and documents referenced therein.
> 
> 
>> The WG will define a "human-friendly" modeling language defining
>> the semantics of operational data, configuration data,
>> notifications, and operations.  This language will focus on
>> readability and ease of use.  This language must be able to serve
>> as the normative description of NETCONF data models.  The WG will
>> use YANG (draft-bjorklund-yang) as its starting point for this
>> language.
>>
>> Language abstractions that facilitate model extensibility and
>> reuse have been identified as a work area and will be considered
>> as a work item or may be integrated into the YANG document based
>> on WG consensus.
>>
>> The WG will define a canonical mapping of this language to
>> NETCONF XML instance documents, the on-the-wire format of
>> YANG-defined XML content.  Only data models defined in YANG will
>> have to adhere to this on-the-wire format.
>>
>> In order to leverage existing XML tools for validating NETCONF
>> data in various contexts and also facilitate exchange of data
>> models and schemas with other IETF working groups, the WG will
>> define standard mapping rules from YANG to the DSDL data modeling
>> framework (ISO/IEC 19757) with additional annotations to preserve
>> semantics.
>>
>> The initial YANG mapping rules specifications are expressly defined for
>> NETCONF modeling.  However, there may be future areas of
>> applicability beyond NETCONF, and the WG must provide suitable
>> language extensibility mechanisms to allow for such future work.
>> The NETMOD WG will only address modeling NETCONF devices and the
>> language extensibility mechanisms.  Any application of YANG to
>> other protocols is future work.
>>
>> The WG will consult with the NETCONF WG to ensure that NETMOD's
>> decision do not conflict with planned work in NETCONF (e.g.,
>> locking, notifications).
>>
>> While it is desirable to provide a migration path from existing
>> MIB modules to YANG data models (modules), it is not a

Re: [IAOC] IETF 72 --> Dublin!

[Andy Bierman]

Fred Baker wrote:
> 
> On Feb 6, 2008, at 9:15 AM, Andy Bierman wrote:
> 
>> However, there are obvious logistical concerns, especially at lunch 
>> time. Is 90 minutes really enough time to bus into town, eat lunch, 
>> and get back?
> 
> Lunch is always a problem. That's why we have a sandwich stand - to 
> diminish exactly this concern.
> 

If 1000+ people are all trying to get lunch at the same time,
a hotel coffee shop and a sandwich stand will probably not cut it.
Adjusting the schedule for a 2 hour lunch would be better if
traveling was the best option for lunch cost/selection.


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

Re: IETF 72 --> Dublin!

[Andy Bierman]

Dave Crocker wrote:
> Ray Pelletier wrote:
>> The venue will be the beautiful Citywest Hotel, "Ireland’s premier 
>> Conference, Leisure & Golf Resort and one of Europe’s most popular 
>> International Conference destinations. The four star Citywest Hotel is 
>> only 20km from Dublin airport and 15km from Dublin City Centre." 
> 
> 
> Ray,
> 
> Every time the IETF has been held in an isolated venue, the experience has 
> been 
> problematic.
> 
> The descriptions of the venue make clear that, once again, the IETF is 
> meeting 
> in a ghetto.  Periodic bus service doesn't counteract that.
> 
> Can you discuss the priorities that led to choosing an isolated venue again?
> 

This choice of venue does not alter my decision process for
attending IETF 72 at all.  Of course downtown locations are better,
but could this be worse than Danvers?  ;-)

However, there are obvious logistical concerns, especially at lunch time.
Is 90 minutes really enough time to bus into town, eat lunch, and get back?
Without lots of frequent shuttles, people will be forced to rent a car.
I would rather pay a little extra in the meeting fee for shuttles
than rent a car for the week.


> d/
> 
> 

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

missing drafts

[Andy Bierman]

Hi,

Several drafts posted on the morning of Feb. 1 are returning '404 not found'
errors.  These 5 were posted in sequence, at 10:36 AM PT:

http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-06.txt

http://www.ietf.org/internet-drafts/draft-badra-ecdhe-tls-psk-03.txt

http://www.ietf.org/internet-drafts/draft-ietf-mip4-generic-notification-message-03.txt

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-15.txt


Any others?

thanks,
Andy
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: joining the IETF is luxury Re: 70th IETF - Registration

[Andy Bierman]

Adrian Farrel wrote:
We shall see, but I don't know that putting up the price necessarily 
fixes the registration income issue. You only have to deter a relatively 
small proportion of attendees to wipe out the increase in charge.


I assume that the converse is also being applied: viz. cutting meeting 
costs. It's hard for us oiks to tell because we only see:

- registration fee
- breakfasts/cookies

Anyway, registration is still the smallest component of attendance for 
me. Hotel and travel are still bigger problems, and I continue to wonder 
whether we could increase attendance (and hence registration income) by 
facilitating cheaper accommodation and travel.




It is easy to rationalize away Yao's concerns, especially for old-timers.
The overall cost of meeting attendance keeps going up, and $700 to attend
the IETF is not a small amount of money.  Simple economics tells us that
the number of attendees will continue to go down, the higher the costs get.

One way to deal with the cost problem is to just ignore it, and focus instead
on making IETF week as valuable as possible for as many people as possible.
I think there has been a lot of progress in this area (Sunday tutorials,
Wednesday beer night, etc. ;-)

(I wonder how much the costs would go down if the meeting ended at 4PM Thursday
instead of noon on Friday, and there was only one plenary night on Wednesday.)



Cheers,
Adrian


Andy


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

Re: Informational vs. Informational

[Andy Bierman]

Paul Hoffman wrote:
On a thread about a specific document that is proposed to be an 
Informational RFC coming through the IETF process:


At 1:12 PM -0400 8/20/07, Sam Hartman wrote:

I've asked the sponsoring AD to make a
consensus call on whether we have sufficient support to be making this
sort of statement.  If not, then I'll be happy to take my document to
the rfc editor.


This is pointless. No one other than an expert at the IETF process could 
differentiate between the two types of Informational RFCs in RFC 
repository (and many IETF process experts would not get it right on the 
first try). An Informational RFC is an Informational RFC regardless of 
the path that got it published.


RFC 2026, sec. 4.2.2 does not appear to designate two different types
of Informational RFCs.  Where is this specified in the standards process?




--Paul Hoffman, Director
--VPN Consortium


Andy

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

Re: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)

[Andy Bierman]

Lixia Zhang wrote:

..
I think we've seen several examples of where the IETF has spent
significant amount of energy, ranging from heated discussions to
specification work, on solutions that simply won't fly.  It would be
useful if that energy waste could be reduced.  Having 'running code' as
a barrier for serious consideration within the IETF may be one 
approach.


I agree that running code should be given extra weight, but I am not
sure that running code should be a requirement for something which is
not well understood yet (some Lemonade WG documents come to mind).


forgive me for jumping into the middle of a discussion (and I did not 
know which of the lemonade doc's the above referred to), but my past 
experience seems suggesting that an attempt to implement a "not well 
understood" idea is a good way towards a better understanding of how to 
make the idea work, or what can be potential issues.




yes!
I tried to resist the 47th rehash of this thread, but... too late...

Within a commercial environment, the organization has to be
fairly convinced that their better mousetrap is going to work,
in order to fund it, productize it, document it, sell it, and support it.

This process will always find more bugs in the mousetrap than
simply documenting it and skipping all the other steps.

If a vendor bothers to do all this, and multiple IETFers can say in a BoF
that they have used the mousetrap and it really does work,
that is worth a whole lot more than "I read the draft and
it looks pretty good".

There is a certain amount of healthy risk that the IESG
can take when chartering new standards-track work.
Prior implementations should not be a gating factor, but
it makes their decision much easier when there is objective
evidence the mousetrap actually works and it is already being
used by the industry.

But implementation and deployment are not enough alone.
There also needs to be some pre-existing consensus that
a standard version could be written and approved by the IETF,
and people are willing to work on it.

The slogan says "rough consensus and running code".
It doesn't say "rough consensus, then running code".
Without running code, there is no deployment.
Without deployment, there is no point to this exercise.

Andy



IMHO, "running code" gets more credit than is warranted.  While it is
certainly useful as both proof of concept and proof of implementability,
mere existence of running code says nothing about the quality of the
design, its security, scalability, breadth of applicability, and so
forth.  "running code" was perhaps sufficient in ARPAnet days when there
were only a few hundred hosts and a few thousand users of the network.
It's not sufficient for global mission critical infrastructure.


it seems to me the above argues that running code is necessary, but not 
sufficient as evidence of a sound design.
(well, that is the interpretation; I have not seen anywhere a claim that 
running code is sufficient, but rather simply to filter out the weed)


Lixia

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





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

Re: Do you want to have more meetings outside US ?

[Andy Bierman]

Brian E Carpenter wrote:


I was talking to a couple of people this week about what I consider to 
be a related issue: the fact that for the two or three wg meetings I'm 
interested in, there's little point in me being at the meeting for a 
whole week.


What about holding two or three meetings smaller meetings a year for 
each area, and then just one big meeting for the full IETF?  That 
would bring down the cost of the individual area meetings and 
therefore the admission fee, make them smaller and therefore capable 
of fitting into a wider range of hotels, and would likely result in 
fewer nights of hotel stay for a lot of people.


The financial fallacy in that is failing to note that about half the
meeting fee isn't used to fund meeting expenses, but to fund continuing
operations of the IETF as a whole (secretariat, RFC Editor, etc.) So
restructuring the meetings would have to be done in a way that preserves
the meetings surplus at about the same annual total as today.



I like the idea of trying a different meeting structure instead of,
or in addition to, the '2 hour status meeting' structure we have now.
It has nothing to do with money, but rather getting work done,
by applying the right resources in the right place at the right time.

I know all about the cross-participation/review argument.
IMO, the ability for a few WGs (or entire area, whatever) to cancel all
WG meetings for the area for an entire day and conduct some
sort of on-site workshop or design meeting, would actually
enforce cross participation.  It might actually resemble
the Real Engineering practices some of us go through in our 'day jobs'.

It should be up to the ADs and the Chairs, and depend on the
situation at hand, as to how many hours or even days worth
of IETF WG meetings they would preempt for such a meeting.



Also, personally, I think that once a year wouldn't be enough to keep
the cross-checking between the areas at a sufficient level. And personally,
even if I'm only active in two or three WGs, the chance to sample what's
going in related and even in unrelated WGs, as well as research groups
and BOFs, makes it well worth staying all week.

Brian



Andy


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

Re: Do you want to have more meetings outside US ?

[Andy Bierman]

JORDI PALET MARTINEZ wrote:

Well I was not indicating that, but simple maths can also say so.

As it seems that more people is contributing from Europe than from US, it
means for more people more traveling time, more time with immigration
issues, etc. Probably we could count from 16 to 40 hours per each
individual. Those hours can be applied to do more IETF work (it is not
necessarily the case, but in any case is time worth saving).



I support your desire to have more non-US meetings,
but maybe not for the same reasons.  There is a certain
moral responsibility to fairly distribute the travel costs
amongst the existing IETF participants.

This has to be balanced with some very practical concerns wrt/
the actual meeting location and facility itself (as the Palmer
House Hilton construction workers demonstrated for us).

My participation in the IETF is self-funded.
The airline flight is not a real factor because I can use FF miles.
The hotel is the major cost but I could choose not to stay
in the IETF hotel and significantly reduce that cost.
(Same for food and beer choices. ;-)

The meeting fee is almost the single
largest monetary expense for me, and it keeps going up.
I would rather the IETF hold sponsored meetings, than the IETF
pick interesting vacation spots all over the world to hold meetings.

I don't have any complaints with the current 'system'.
I just want to meeting fees to be as low as possible, and the locations
to be known far enough in advance so some frequent flier award seats are left.


Regards,
Jordi


Andy







De: Stewart Bryant <[EMAIL PROTECTED]>
Responder a: <[EMAIL PROTECTED]>
Fecha: Sun, 29 Jul 2007 16:04:23 +0100
Para: <[EMAIL PROTECTED]>
CC: 
Asunto: Re: Do you want to have more meetings outside US ?


Do we have any firm evidence that we would get more work
done if we had more meetings outside the US?

Stewart









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





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

take the train in Chicago

[Andy Bierman]

FYI,

According to the WEB, it is really easy and really cheap
to take the train from the O'Hare airport to the IETF hotel.

(I have not verified this info however...)

From the airport:

 1) Walk east on the terminal 2 CTA Rail Walkway to the station

 2) Take the Blue line train southbound (fare $2 USD)

 3) After approx. 45 min. ride, get off at the Monroe/Dearborn stop

 4) Exit through the Monroe/Adams Mezzanine

 5) Walk 1 block east on Monroe St. to the hotel at 17 E. Monroe St.


Andy


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

Re: consensus and anonymity

[Andy Bierman]

Brian E Carpenter wrote:

Combined response:

On 2007-05-31 23:07, Andy Bierman wrote:

I think the inability of the IETF to make decisions in
an open, deterministic, and verifiable manner is a major flaw.
It promotes indecision and inaction.


I think the ability of some other SDOs to take go/no go decisions on
unpublished documents by a fixed deadline, based on corporate voting,
is a major flaw. It promotes superfical review and flawed documents.



This has more to do with corporate culture and the low priority
of 'quality' in the business model.  The IETF's reluctance to
accurately quantify consensus is a different matter.  Making bad decisions
on time is not the only other option.



On 2007-06-01 01:14, Andy Bierman wrote:

I don't understand why such a comment needs to be private.
Once the issue comes to light in the WG, it is no longer going
to be private.

You are assuming the Chair can and should be a proxy for a
WG member who wishes to remain anonymous.  I disagree. 


Why is this a problem? Again, our goal is to discover technical
flaws (or make technical improvements) in drafts. What does it
matter if someone has good reason to request anonymity and to use
the AD (or anyone else) as a proxy?




This is only a problem as the debate escalates.
It is not a problem bringing issues to light.
I suppose if the Chair is willing to proxy for both
sides of the issue, and make it clear when they are making
a comment as a proxy or as a Chair, then it is not an issue.



On 2007-06-01 04:09, Henning Schulzrinne wrote:

I think a fair vote requires

- a clear definition of who can vote 


Which is fundamentally impossible in the IETF.

On 2007-06-01 04:22, Lakshminath Dondeti wrote:
Can anyone point to me where it is written that voting at a meeting is 
the decision making process when rough consensus (hum or whatever) has 
been inconclusive?




There must be something in between humming and corporate voting,
which is better than flipping a coin and arbitrarily picking a winner.


Definitely, nowhere. But there is a model that has been used
where a WG agrees *by rough consensus* to accept an arbitrary decision
method when a technical rough consensus cannot be reached. Example:
http://www1.ietf.org/mail-archive/web/ietf/current/msg46040.html

   Brian

__


Andy

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

Re: consensus and anonymity

[Andy Bierman]

Michael Thomas wrote:

Andy Bierman wrote:

Michael Thomas wrote:

I think the inability of the IETF to make decisions in
an open, deterministic, and verifiable manner is a major flaw.
It promotes indecision and inaction.


Is there any human decision making process that has all of these
characteristics? Or that even believes that those are axiomatic?


no, but there is some evidence that the IETF does not regularly
make timely and effective decisions, relative to the expectations
of the participants.  IMO, this is due to a flawed process which
only works well in "landslide" decisions.  The track record for
close or difficult decisions is not very good.



Dishonesty by the management is a problem regardless of what system we
have. Most wg's these days have two chairs, so collusion would need 
to be
at least that deep, and probably require an AD to be on board too. If 
that

really were the case, I doubt any system is likely to perform very well.



Only transparency can prevent corruption.


Preventing corruption is not the end product of the IETF. Producing
good/useful protocol specs is the end product of the IETF. Thus
"corruption" is just one consideration. Life is messy that way.



The end product is a document.
The document is a result of decisions made (or punted).
The text in the document is fair game for any kind of comment,
as long as the comment is made openly for everyone in the WG
to consider.

If there was an anonymous mailing service, such that people could
comment on WG issues without revealing their identity, then how
do we know everybody using the service will only make their comment
once?  What is to prevent them from making the same comment N times,
hoping to deceive the WG into thinking the comments represent the
views of N people?




But this cultural thing does bug me. It seems unsatisfying to me that 
our

pat answer to cultural differences is "become more western".  The
language issue is already asking quite a lot of the rest of the world.



I don't see the cultural bias here.


Which culture are you from?


Kalifornia -- as if that matters.

The IETF is not an academic exercise.
I have found that people from the academic culture are appalled
at how their documents are treated by others in the IETF.
In the competitive culture of the IETF, documents are often
attacked (or ignored) in ways that are not common in the academic world.
This is unfortunate, but not enough of a reason to allow the
IETF decision making process to be even more murky and secretive.




  Mike




Andy

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

Re: consensus and anonymity

[Andy Bierman]

Sam Hartman wrote:

"Andy" == Andy Bierman <[EMAIL PROTECTED]> writes:


Andy> This is not an alternative.  If you are not willing to make
Andy> your technical objections to a technical specification
Andy> publicly, then they cannot be part of the IETF
Andy> decision-making process.

At one level I agree here.


Andy> What's to prevent a WG Chair from "padding" the anonymous
Andy> "votes"?  If 5 people in public (WG meeting or mailing list)
Andy> are for some proposal, and the Chair says, "I heard from 6
Andy> people who are against this, but don't want their identities
Andy> known, so the proposal is rejected."  Not acceptable.


I think that would be unacceptable.  I think that a WG chair going to
people who expressed private concerns and saying something like "Hey,
you need to express your concerns in public.  They are shared; if all
of the people who have these concerns bring them forward then we would
have enough interest in dealing with this issue.  You have a week," is
entirely fine.

I also think it is fine for a WG chair to look at private technical
concerns, realize they are correct and raise them to the WG.  "I
received a private concern; that mail pointed out that the following
trivial attack will break the security of this protocol.  We are not
moving forward until someone fixes this problem or someone explains
why I'm misunderstanding the situation."



I don't understand why such a comment needs to be private.
Once the issue comes to light in the WG, it is no longer going
to be private.

You are assuming the Chair can and should be a proxy for a
WG member who wishes to remain anonymous.  I disagree.



It's probably even fine to say "I received a lot of private concerns.
Are the people willing to make public comments firmly behind their
support?"


I am specifically referring to technical comments.
I realize that WG members may have non-technical concerns
which are appropriate to convey to the Chair privately.

I think the IETF consensus process is severely flawed.
Many times I have encountered deadlocks because 3 people
are strongly for something, 3 people are strongly against it,
and 40 people couldn't care less which way the decision goes.
Determining consensus based on hearsay and humming makes matters
even worse.



--Sam





Andy



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

Re: consensus and anonymity

[Andy Bierman]

Michael Thomas wrote:

Andy Bierman wrote:

Spencer Dawkins wrote:

Just following up here...

From: "Lakshminath Dondeti" <[EMAIL PROTECTED]>


But, I wonder why anonymity is an important requirement.  The 
mailing list verification has at least two properties that are more 
important to the IETF: the archives provide for anyone to be able to 
verify the consensus independent of the IETF hierarchy (chairs, ADs 
and whoever); further the archives provide a means to verify the 
consistency of any IETF participant, chairs or ADs at any given 
moment, candidates for WG chair and I* positions, and anyone in 
general.


We've been telling new WG chairs for several years that

- they really need to have most discussions in public/on mailing lists,

- we recognise that some people aren't comfortable challenging others 
in public, and


- we recognise that this discomfort may be more common in some 
cultures than in others.


So, for reasons that both John and Lakshminath identified, we've been 
asking WG chairs to encourage participants to engage in public 
discussions, but to be receptive to private requests for assistance 
on how to carry out those discussions.


The alternative - a WG chair who tells the working group that the 
apparent WG consensus on the mailing list is being overruled because 
of anonymous objections that the WG chair cannot share with the WG, 
or because of private objections that the WG chair is "channeling" 
from a back room - would make voting seem reasonable (or, to use Mark 
Allman's characterization in another thread, "seem charming").




This is not an alternative.
If you are not willing to make your technical objections to a technical
specification publicly, then they cannot be part of the IETF 
decision-making

process.


If that's true, then why do we have hums at wg meetings at all?
A hum doesn't give the reasoning; it's a binary quantity.



I think the inability of the IETF to make decisions in
an open, deterministic, and verifiable manner is a major flaw.
It promotes indecision and inaction.


What's to prevent a WG Chair from "padding" the anonymous "votes"?
If 5 people in public (WG meeting or mailing list) are for some
proposal, and the Chair says, "I heard from 6 people who
are against this, but don't want their identities known, so the
proposal is rejected."  Not acceptable.


Dishonesty by the management is a problem regardless of what system we
have. Most wg's these days have two chairs, so collusion would need to be
at least that deep, and probably require an AD to be on board too. If that
really were the case, I doubt any system is likely to perform very well.



Only transparency can prevent corruption.


But this cultural thing does bug me. It seems unsatisfying to me that our
pat answer to cultural differences is "become more western".  The
language issue is already asking quite a lot of the rest of the world.



I don't see the cultural bias here.
I see the bias in "English only", but these are public
standards being developed.  Everybody in the IETF should
be able to read all of the comments made on a draft, not
just a privileged elite.


  Mike




Thanks,

Spencer


Andy



Andy

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

Re: consensus and anonymity

[Andy Bierman]

Spencer Dawkins wrote:

Just following up here...

From: "Lakshminath Dondeti" <[EMAIL PROTECTED]>


But, I wonder why anonymity is an important requirement.  The mailing 
list verification has at least two properties that are more important 
to the IETF: the archives provide for anyone to be able to verify the 
consensus independent of the IETF hierarchy (chairs, ADs and whoever); 
further the archives provide a means to verify the consistency of any 
IETF participant, chairs or ADs at any given moment, candidates for WG 
chair and I* positions, and anyone in general.


We've been telling new WG chairs for several years that

- they really need to have most discussions in public/on mailing lists,

- we recognise that some people aren't comfortable challenging others in 
public, and


- we recognise that this discomfort may be more common in some cultures 
than in others.


So, for reasons that both John and Lakshminath identified, we've been 
asking WG chairs to encourage participants to engage in public 
discussions, but to be receptive to private requests for assistance on 
how to carry out those discussions.


The alternative - a WG chair who tells the working group that the 
apparent WG consensus on the mailing list is being overruled because of 
anonymous objections that the WG chair cannot share with the WG, or 
because of private objections that the WG chair is "channeling" from a 
back room - would make voting seem reasonable (or, to use Mark Allman's 
characterization in another thread, "seem charming").




This is not an alternative.
If you are not willing to make your technical objections to a technical
specification publicly, then they cannot be part of the IETF decision-making
process.


What's to prevent a WG Chair from "padding" the anonymous "votes"?
If 5 people in public (WG meeting or mailing list) are for some
proposal, and the Chair says, "I heard from 6 people who
are against this, but don't want their identities known, so the
proposal is rejected."  Not acceptable.



Thanks,

Spencer


Andy

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

Re: RFID

[Andy Bierman]

Philip Guenther wrote:

On Mar 27, 2007, at 8:10 PM, Andy Bierman wrote:
...

I find it rather annoying to listen to the constant interruptions,
reminding people of the process.  The only reasons for such an
interruption are:

...

 2) you plan to base your opinion of the imminent comment on either
who says it or more likely, what company they work for

In either case, the interruption is not adding value to the technical
discussion.


Are you saying that we should not consider reputation when judging
the technical soundness of comments?  I disagree.  I can think of
at least three cases in which knowing which person said something
will affect my interpretation of a comment.



I am saying that the interruption is annoying, and if it
is really important to record the speaker's name for the
minutes, then post little signs on the microphone that
say "state your name!".

If that doesn't work, then interrupt the person after it
is determined that a really important statement has been
made and the speaker of those words needs to be identified for the record.

Otherwise, being quiet and letting the person finish their sentence
would be better than loud and repeated interruptions.

Maybe we could get a good DoS attack going in these meetings.
Somebody starts to say something important at the mike,
but forgets to state their name.

Somebody in the back then screams at them to state their name.

Person at the mike screams back "Stand up and make your comment
into the microphone".  Person in the back walks to microphone,
forgets to state their name, says "state your name", but is
interrupted by someone in the back yelling "You state Your name!" :-)

Andy






1) When a working group is discussing something involving other WGs
   or areas (security in an apps group, etc), knowing that a comment
   came from someone who *is* strong in that area does affect whether
   I consider it as resolving the question.  Hearing "TLS can/can't
   do what you need" from a random apps WG chair means something
   different than hearing it from, say, EKR.  For the former, I
   might ask for details to find whether the person might be thinking
   of a similar-but-not-quite case, while for the latter I might
   jump directly to asking for a direct recommendation on where to
   look next.

2) Whenever someone uses the phrase "in my experience", I cannot
   evaluate their statement without some knowledge of the breadth
   their experience.  While asking the person to describe that would
   also suffice, it saves a lot of time if people can let their
   name serve as a placeholder.

3) some people are quite understated in their comments, others more
   pedantic.  Evaluating how strongly held someone's opinion is often
   involves knowing their style.


Philip Guenther






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

Re: RFID

[Andy Bierman]

Jeffrey Hutzelman wrote:



On Tuesday, March 27, 2007 03:51:56 PM -0700 Andy Bierman 
<[EMAIL PROTECTED]> wrote:



http://en.wikipedia.org/wiki/Wonk_%28slang%29

According to wikipedia, a policy wonk is
someone knowledgeable about and fascinated by details of government
policy and programs

If that is derogatory then I'm sorry.


It carries a derogatory connotation.



IMO it is accurate to say there are many people in
the IETF that fit this description.


And I don't dispute that.  I just don't think it's appropriate to apply 
that description to people who say "XXX, tell us your name!" the third 
time someone gets up to the mic without saying their name.


I find it rather annoying to listen to the constant interruptions,
reminding people of the process.  The only reasons for such an
interruption are:

 1) it is very important to you that detailed and accurate minutes
record every "he said, she said" comment made at the microphone

 2) you plan to base your opinion of the imminent comment on either
who says it or more likely, what company they work for

In either case, the interruption is not adding value to the technical
discussion.



-- Jeff




Andy



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

Re: RFID

[Andy Bierman]

Jeffrey Hutzelman wrote:



On Tuesday, March 27, 2007 02:42:19 PM -0700 Andy Bierman 
<[EMAIL PROTECTED]> wrote:



There are so many Process Wonks in the IETF who feel it
is their sworn duty to yell "State your name please!"


I think it's unfair to call people who do that "process wonks" or any 
other derogatory term.  Most of them are people who want to know who is 
speaking. Some of them are people who assume the rest of the room want 
to know who is speaking, probably don't, and probably don't feel 
comfortable speaking up and saying so.






http://en.wikipedia.org/wiki/Wonk_%28slang%29

According to wikipedia, a policy wonk is
someone knowledgeable about and fascinated by details of government policy and 
programs

If that is derogatory then I'm sorry.
IMO it is accurate to say there are many people in
the IETF that fit this description.


that said...


I don't think
we need to introduce expensive technology into the mix.


I very much agree with this.


-- Jeff




Andy

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

Re: RFID (was: identifying yourself at the mic)

[Andy Bierman]

Schliesser, Benson wrote:

Eric-
 
It sounds like your argument is: "We're too incompetent to say our names 
at the mic, so we're probably too incompetent to use a RFID system."  
Did I get that right?
 


This sounds like a Rube Goldberg joke, not a serious thread.
Could we possibly find a more over-engineered solution
to such an unimportant problem?  I doubt it.

There are so many Process Wonks in the IETF who feel it
is their sworn duty to yell "State your name please!"
every time somebody steps to the mike, that I don't think
we need to introduce expensive technology into the mix.
How much are the IETF meeting fees going to go up to pay for RFID name
badges anyway?


While I'm certainly not going to defend the competence of every IETF 
participant, I don't find much merit in that argument. In my 
(unscientific) first-hand experiences, it seems that most people 
do manage to wear their nametags at the meeting. And many of the names 
on those tags are of cultural origins other than my own, i.e. from a 
non-English speaking country. If I could actually see the name of the 
person speaking, it seems like a great improvement over hearing a name 
which is unintelligible to my ears or hearing no name at all. And if 
somebody forgets their RFID-badge, then I'm no worse off than I am today.
 
In other words, I think we could come up with a system that worked well 
enough to be a net improvement over our current operational model.
 
On the other hand, I am amused by your idea of scanning the streets for 
RFID responses that look like IETF-badges. Then my robot army could 
track down and kill all IETF participants whom oppose my plans to take 
over the Internet! Or maybe I could just use them for some fun practical 
jokes instead...
 
Cheers,

-Benson


Andy

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

Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC

[Andy Bierman]

John C Klensin wrote:


--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<[EMAIL PROTECTED]> wrote:


"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> writes:


Arguments on complexity are too easy to make. Every time a
proposal is made I hear the complexity argument used against
it. Everything we do is complex. Computers are complex.
Committee process usually increases complexity somewhat.

If an argument can always be used what is the discrimination
power?

How about using answers to the question "Is this complexity
needed?" as a discriminator?

Sometimes, there is no better solution than one with certain
complexity.  That isn't inherently bad.

I'm not sure the need for this particular complex solution was
demonstrated.  I don't recall anyone defending it.  The
experimental track thus seems appropriate, if it should be
published at all.


But that was precisely where the other thread, if I recall, came
out.  It wasn't an argument against complexity.  It was an
argument about introducing another optional way of doing things
because we _know_ that many options lead to worse
interoperability.  And it was a suggestion/ request that, before
this document was published in _any_ form, that it at least
acquire a clear discussion as to when one would select this form
over the well-established ASN.1 form for which there is existing
deployment, existing tools, etc.  Put differently, we all know
that this _can_ be done but, if there is another solution
already out there, widely deployed, and in active use, a clear
explanation about _why_ it should be done and under what
circumstances it is expected to useful is in order.

That suggestion about an explanation was a specific request
about the document, not idle theorizing about the character of
ASN.1 or the nature of complexity.

And, again, pretending that the discussion didn't occur
impresses me as a little strange.


I was going to raise this issue, but I deleted the mail when I realized
this is going to be an Experimental RFC (according to the subject line).

I don't think it harms interoperability to introduce an experiment
into the mix.  If deployment and useful tools follow, then maybe
a later revision can move to the standards track.



 john



Andy

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

Re: Protest: Complexity running rampant

[Andy Bierman]

Dave Crocker wrote:



Fred Baker wrote:

 is it a bad thing to provide
the expressive nature of ASN.1 in a human-readable and popular data 
representation?


The one thing IETF standardization certainly ought to imply is that 
there is a real constituency interesting in using the specification in 
the near-term.


Who wants to use this spec, now, and why?


I almost sent an email asking this question when I read the drafts.
My reaction was "This seems like a lot of stuff to put on the
standards track without being the output of a WG."

I didn't, because I figured there must be some significant
constituency that wants this standardized.  So, is there or not?



d/


Andy


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

Re: IETF 68 hotel full

[Andy Bierman]

Andrew G. Malis wrote:
You're much better off following this link (but I think you have to use 
Internet Explorer for it to work):
 
http://local.live.com/default.aspx?v=2&cp=50.09292~14.437961&style=r&lvl=17&tilt=-90&dir=0&alt=-1000&rtp=null~null 



You can very easily see the Hilton.
 


thanks.
Somebody sent me a private email and said Friday (3/23) was sold out at the 
hotel.
When I used the online form (and called the 800#), I was trying to checkout on 
3/25.
When I entered 3/23 as the checkout date in the online form, I was able to
get a room at the IETF rate.



Cheers,
Andy



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

Re: IETF 68 hotel full

[Andy Bierman]

Janet P Gunn wrote:


IIRC the hotel web site has a map.  You could use that to find the names of
nearby streets.



Really? Where?
The one I found didn't have street names.

http://www1.hilton.com/en_US/hi/hotel/PRGHITW/directions.do#localmap


Janet


Andy




Andy Bierman <[EMAIL PROTECTED]> wrote on 12/18/2006 01:37:43 PM:


Hi,

There is only one hotel listed for IETF 68:

http://www3.ietf.org/meetings/68-hotels.html

There are no more rooms at the IETF rate, and perhaps
at any rate.  The online form says no rooms are available
that week.

I'm having trouble finding "Pobrezni 1 186 00 Prague 8 Czech Republic"
with online maps.

Does anybody know which hotels are close to the Hilton Prague?

thanks,
Andy



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







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

IETF 68 hotel full

[Andy Bierman]

Hi,

There is only one hotel listed for IETF 68:

http://www3.ietf.org/meetings/68-hotels.html

There are no more rooms at the IETF rate, and perhaps
at any rate.  The online form says no rooms are available
that week.

I'm having trouble finding "Pobrezni 1 186 00 Prague 8 Czech Republic"
with online maps.

Does anybody know which hotels are close to the Hilton Prague?

thanks,
Andy



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

Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)

[Andy Bierman]

Hallam-Baker, Phillip wrote:
From: Keith Moore [mailto:[EMAIL PROTECTED] 


that's my understanding also.  but nothing you said here 
contradicts my statement.  if connection of the host to the  
network is predicated on having the host conform to whatever 
arbitrary policy the network wishes to impose on how the host 
is configured, then it's unreasonable. 


So what if it is unreasonable.

My network, my rules. If you don't like them go to the nearest Panera and use 
their free WiFi.

If you want to connect to my network, my rules apply. That's not arbitrary, 
that's my right and my choice.



I'm unclear on what host requirements NEA is proposing to add.
The reality is that I have about 2 giant corporations to choose
from for Internet connectivity where I live.  I don't want either
one of them installing mandatory software on my computers that
denies access to the Internet if any "unapproved" applications
are found.  I would rather decide which applications I get to run,
and if the ISP chooses to firewall certain protocols, then fine.



Andy

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

Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

[Andy Bierman]

Eliot Lear wrote:

Andy Bierman wrote:

I don't agree that this is low-hanging fruit.
The server component of this system seems like a wonderful
new target for DDoS and masquerade attacks.

Well, first of all I don't see why this is any different than a radius
server.  In fact it could be that the access box forwards information in
a very similar way.  But let's say that it doesn't work that way just
for yucks.  Another approach is that the clients themselves must have a
server on them and the queries go the other way.  In this case the
server need only check either a source address or a transaction ID. 
Furthermore, there is no reason for clients outside of that AS to have

access to that server, so it's a good candidate for an ACL.  Of course
this creates a risk of attack on the clients themselves, which brings me
to one of my greater concerns:

In many of the mechanisms that communicate between client and network we
are not finding good ways to prove the legitimacy of the service to the
client.  This is an area that perhaps it would be good to get the IRTF
to work on.



My comment was on Harald's characterization of this work effort
as 'low hanging fruit'.  IMO, that term is reserved for huge gains
for very little effort.  I don't think that is the case here.


Eliot



Andy



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

Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

[Andy Bierman]

Harald Alvestrand wrote:
A typical NEA case (taken out of what Cisco's NAC is supposed to be good 
for):


- Worker goes on holiday, takes laptop
- New attack is discovered that exploits a newly discovered Windows 
vulnerability

- Patch is created, distributed and installed
- NEA posture requirement is increased to "must have patch"
- Worker comes back, plugs in laptop

Without NEA-like functionality:
- Worker is admitted
- Worker gets attacked & compromised
- IDS & other alarms go off
- Remediation efforts do what they usually do

With NEA:
- Worker gets sandboxed
- Worker gets upgraded
- Worker gets admitted
- No compromise, so no remediation

No ill intent on the part of any participant (except the attacker). Just 
a TCO issue.


The fact that some fruit is low-hanging doesn't mean it's not worth 
picking.


I don't agree that this is low-hanging fruit.
The server component of this system seems like a wonderful
new target for DDoS and masquerade attacks.




  Harald



Andy




Alan DeKok wrote:

Brian E Carpenter <[EMAIL PROTECTED]> wrote:
 

What if your contractor has carefully configured the laptop to
give all the right answers? What if it has already been infected with
a virus that causes it to give all the right answers?



  Yes, that's a problem with NEA.  No, it's not a problem for many (if
not most) people using NEA.

  The people I talk with plan on using NEA to catch the 99% case of a
misconfigured/unknown system that is used by a well-meaning but
perhaps less clueful employee or contractor.  The purpose of NEA is to
enhance network security by allowing fewer insecure end hosts in the
network.

  No one can prevent a determined attacker from getting in.  But by
providing fewer hosts for him to attack, the attacks become less
feasibly, and more visible.

  Alan DeKok.

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

  



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





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

Re: Proceeding CDs

[Andy Bierman]

IETF Administrative Director wrote:

The IAOC is preparing the 2007 budget and would like feedback on whether
or not to continue producing the IETF meeting CDs of the Proceedings.

It has been suggested as a way of employing limited Secretariat labor
more productively that the IAOC discontinue production of the Proceedings
on CDs and, instead, make the files available collectively on the web site
for each meeting in a zip file for downloading.  


Is there strong rationale for maintaining production of the CDs?



No.
IMO, free online retrieval of IETF proceedings is sufficient.
Spend the time and money on something more important.

My 2 cents on data format:

If I really wanted to have a CD of the proceedings,
then I would want to retrieve a .iso file from the archive.

(Moving from the Print Era to the Electronic Age is hard...
I just recycled my collection of paper IETF proceedings a year ago.
I bet some of you still have every one!)



Ray Pelletier
IAD


Andy

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

Re: Its about mandate RE: Why cant the IETF embrace an open Election Process

[Andy Bierman]

Hallam-Baker, Phillip wrote:
From: Nelson, David [mailto:[EMAIL PROTECTED] 


I think NOMCOM is like a Representative Town Meeting, in 
which the representatives are chosen by a random selection 
process, rather than by election.  The outcome, which 
supports in-depth consideration and substantial, informed 
debate, is much the same.


The NOMCON process is certainly grounded in academic theories of governance 
that were popular in the 80s. Many of them attempt to provide a practical 
implementation of Rawl's theory of justice.

The problem I see is NOT who gets elected but the lack of authority and 
mandate. The reason that the time spent on NEWTRACK was wasted is that nobody 
feels that they have a mandate to change anything.

As a result the IETF is a standards body with 2000 active participants that produces on average less than 3 standards a year and typically takes ten years to produce even a specification. 



I think Quality and Timeliness are real problems (unlike this one),
but the IETF output is much better than you suggest, and IMO it
is improving.

I do not want NOMCOM to be replaced by an election process.
I want dedicated volunteers to continue the in-depth selection
process.  I have no faith whatsoever that the community-at-large
would put any significant effort into an election process.  I am concerned
that financially motivated companies would abuse the election process
to gain more control of the IETF.  Then massive efforts would be needed
to fix the new mess.

Andy



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

Re: [Fwd: IETF Process discussions - next steps]

[Andy Bierman]

Brian E Carpenter wrote:

I was quite surprised to discover that this message is not
in the mailing list archive, so I am repeating it.
A copy certainly reached the newtrk WG prior to
its closure.

 Original Message 
Subject: IETF Process discussions - next steps
Date: Thu, 10 Aug 2006 11:41:47 +0200
From: Brian E Carpenter <[EMAIL PROTECTED]>
Organization: IBM
To: IETF discussion list 

Here are my conclusions from the plenary discussion
and the General Area open meeting at IETF 66.

1. Conclusions from plenary discussion on Newtrk issues
(draft-carpenter-newtrk-questions-00.txt)



IMO, there are IETF-wide and area-wide standards-track
advancement issues are varying importance.

I think each AD should at least consider (and hopefully write down)
what the "advancement policy" is for their area.

For example, we have learned through experience that advancement
of MIB modules is quite problematic, even though it is very straight-forward
to define and evaluate the interoperability requirements.

Vendors have been rather reluctant to respond to implementation surveys.
(This isn't that surprising, since SW engineers usually have to fill
out the surveys, and we hate to write documentation :-)
Even when this seemingly harmless survey is returned, many respondents
say they don't believe this effort is of any value.

So the reports are inaccurate and difficult to obtain.  Worse yet,
decisions to keep or deprecate MIB objects are based on these reports.
In the Entity MIB WG, we actually found our efforts to deprecate
some MIB objects (per SOP) during advancement to be harmful to
interoperability.

I believe we now have an unofficial "don't ask, don't advance" policy.
That is, the WG Chairs won't attempt to advance RFCs containing MIB modules
beyond Proposed Standard anymore, and the ADs won't ask them to do so.

Yet, I believe there is some value for operators to know the
difference between a mature MIB module like RMON-MIB and the
first version of a MIB module like RAQMON-MIB.
The SMI sort of provides that info, but not very clearly to non-experts.



Andy






A clear theme in the plenary discussion in Montreal was "declare victory."
Unfortunately, in reading the notes and listening to the audio
recording, and reading subsequent emails, it is also clear that
different speakers meant different things by this phrase - anywhere
from clarifying today's standards track, through reducing it to two
or one stages, to simply sitting down and shutting up. Although
on the order of 40 people out of several hundred in the plenary
appeared to believe that formal changes to the standards process
should be made, and some people are ready to do work (thanks!)
there was no firm consensus for a given direction (as there never has
been in the Newtrk WG).

One useful observation was that there is nothing in present
rules and procedures to prevent the writing and publication
of overview standards documents ("ISDs" in Newtrk parlance),
as long as they fit into RFC 2026 rules as Applicability
Statements.

A need was observed for lightweight documentation of the real
world deployment status of individual standards, as concrete
feedback from running code. Again, no rule prevents this today,
but neither do we have guidelines as to the format, status
and indexing of such documents.

My conclusions are that:

1.1. There is insufficient pressure and energy in the community
to justify the effort of reaching consensus on formal changes
to the standards process at this time.

1.2. For complex standards where a normative or informative
overview document would be beneficial, nothing in today's
rules and procedures prevents interested parties from
writing and submitting such documents within the rules set
by RFC 2026, and such efforts should be welcomed.

1.3. The community should be encouraged to produce documentation
of deployment and interoperability of individual IETF standards,
even if there is no proposal to advance them on the standards track.
Such documents should be directed towards efforts to update
IETF standards and/or to document errata and operational issues.
A more systematic framework than today's implementation reports
would be beneficial.

1.4. The newtrk WG should be closed.

2. Conclusion from GenArea mini-BOF on IESG structure and charter.

It seemed clear in the room that people felt there was not a serious
enough problem with RFC 3710 to justify a significant effort.
There was some support for undertaking at least the first step:
 * List Tasks that Currently Gate on the IESG
in order to document whether there is in fact a problem worth
solving.

My conclusion is to ask John Leslie to lead a small team to carry out this
very specific task for the information of the community.

3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)

It seems there is some feeling that the RFC is beginning to show
its age, and would be worth updating.

My conclusion is that the best first step is to ask Margaret
Wasser

Re: Weekly posting summary for ietf@ietf.org

[Andy Bierman]

Noel Chiappa wrote:

> From: "todd glassey" <[EMAIL PROTECTED]>

>>  26.23% |   32 | 26.08% |   250016 | [EMAIL PROTECTED]
>>  10.66% |   13 | 10.48% |   100481 | [EMAIL PROTECTED]
>>   7.38% |9 |  5.77% |55362 | [EMAIL PROTECTED]
>>   6.56% |8 |  5.44% |52194 | [EMAIL PROTECTED]

> Is this a NOT SO SUBTLE form of harassment?.

Get a grip. This table is produced automatically every week.

If you have been sending more messages than any other three people put
together recently, you have only yourself to blame - and most of the rest had
realized that before this table came out.



1) I totally agree with Noel that an automated report is objective
   and not intended to pick on anybody

2) I don't understand why receiving email you don't want is such
   a big deal.  Learn how to use filters and the delete button.

3) I find it ironic that sometimes the only garbage posting to this list
   during a given week is the automated report telling me how much
   garbage posting occurred during the week.



Noel


Andy

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

Re: RFC Editor RFP Review Request

[Andy Bierman]

todd glassey wrote:

So let me ask the obvious thing... why is the RFP content being voted on?
This is a business decision in regard to services and process. Why is any of
it open to review inside the IETF?



Because the lunatics want to run the asylum?  ;-)

Seriously though, it seems to me that most people agree
with us, and want to let the IAD and IESG do their jobs,
and stop all this obsessing over every detail of our "Process".

How about if we get that "quality" and "timeliness" thing
under control before spending a lot of time agreeing on
the 427 most important factors in selecting IETF meeting locations?

(Just my $0.02.  OK, maybe it's the whole dollar :-)




Todd


Andy


- Original Message - 
From: "John C Klensin" <[EMAIL PROTECTED]>

To: "Ted Hardie" <[EMAIL PROTECTED]>; "Jeffrey Hutzelman" <[EMAIL PROTECTED]>;
"Allison Mankin" <[EMAIL PROTECTED]>; "IETF Administrative Director"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Wednesday, July 26, 2006 2:56 PM
Subject: Re: RFC Editor RFP Review Request




--On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie
<[EMAIL PROTECTED]> wrote:


At 3:28 PM -0400 7/26/06, John C Klensin wrote:

The other is that, to some readers, it appears to impose
binding requirements on how the RFC Editor deals with input
from the IESG, either directly (as in "if we recommend that
this text be inserted, you must insert it or not publish") or
indirectly (as in "if you don't follow our recommendations,
we will see to it that your funding is cut off").  For those
of us who believe that it is important to the Internet that
the RFC Editor function as an independent, cooperating,
entity rather than as a subsidiary of the IETF, that level of
requirement is not acceptable (that consideration is the
source of this discussion about aspects of the RFP and what
should, or should not, be in it).  While the IETF can attempt
to establish links to particular funding sources and apply
leverage that way (which some of us are trying to
discourage), it is also beyond the ability of the IETF to
give itself the authority to impose such requirements
directly, any more than approval of a document as an IETF
Standard can force someone to conform to it.

I don't agree with this understanding, but I appreciate your
taking the time to clarify it.  The "imposition of binding
requirements" you cite above is, from my way of looking at it,
instead a description of how the two cooperating entities
cooperate.  Putting descriptions of that kind into the RFP
(or, rather, references to them) is useful for a potential
respondent so that know what timelines and level of external,
unpaid effort to expect from the IETF.  Other ways around this
seem to have their own headaches. For example, requiring  the
publisher of the independent stream to establish that a
document  does not inappropriately usurp an unregistered
standards-dependent  IANA  namespace or  reserved protocol
bits would otherwise take the time and talents of the
publisher's review teams.  That slows the stream or increases
costs in a different way.

Then I think we are more or less on the same page.  The
challenge now is to get the RFP to appropriately reflect that
shared understanding.

john




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



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





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

Re: LA -> San Diego transportation (Was: Re: Meetings in other regions)

[Andy Bierman]

Dave Crocker wrote:


Clint Chaplin wrote:

One data point: IEEE 802 is in San Diego this week, and I've met at
least one attendee who flew through LAX to get here; that is, he took
LAX -> SAN as his last leg.


the flight is so short, one can feel guilty taking it.  however the effort to
rent a car from an airport, drive through Southern California traffic, and then
either have the car sit for a week or try to dump it upon arrival, all make
taking that short flight a reasonable choice.


First, I want to clarify my original mail.
I meant that if you live in LA, it doesn' pay
to fly to San Diego.  It's way faster and cheaper
to drive your own car there instead of flying.

Second, remember that the San Diego location is not close
to very many good dining and drinking spots, so having
a car at the next IETF will be useful.

Third, renting a car in LA and driving is a really bad idea
(instead of getting a free connecting flight) unless you
want to visit LA or the area between LA and San Diego while you
at the next IETF.  (Trust me, if you have never been to
Laguna Beach, go there if you want to see what SoCal is
really like.)




d/


Andy

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

Re: Meetings in other regions

[Andy Bierman]

Marshall Eubanks wrote:

Nobody flies from LAX to San Diego because it ends up taking
twice as long as driving for 10 times as much, so don't expect
lots of flights from LA.

For visitors, you might want to fly to LAX, rent a car,
drive down the 405, and take a detour to the Laguna Beach
area on the way down (or back) for a little vacation time.

BTW, 3 comments on some real topics:

 - Meeting location is a minor factor for me when I go to the IETF meeting.
   Whether or not I have active drafts in WGs (author or chair) is the gating
   factor whether I go to the IETF at all, regardless of where it is located.

 - I strongly support Fred Baker's notion of location fairness,
   just as I did when Fred was IETF Chair.

 - I didn't find a terminal room, but instead a giant 'break room'
   for ad-hoc meetings and food breaks.  This was wonderful, and
   about time! 802.11 has thankfully made the terminal room obsolete.
   I want this format every time.  Please consider 2 enhancements:

 - A/C around the perimeter for laptop power
 - beverages available (at least pitchers of water) all day



Andy




On Jul 17, 2006, at 8:45 AM, Marshall Eubanks wrote:


Hello;

On Jul 17, 2006, at 8:21 AM, <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> wrote:



John C Klensin wrote:


It also means such things as:

* picking places within those countries or regions that have
good airports with easy (and multiple) international
connections.  Even San Diego is a little marginal in that
regard.  Based on experience in the last year or so, I'd
suggest that Cape Town and Marrakech (suggested in another
posting) should be utterly disqualified (although J-berg and
Casablanca are more plausible on this dimension).


Some data about San Diego: Today, the flight information page on San
Diego "International" Airport web site shows a couple of flights
to/from Mexico and a couple to/from Canada -- all the others are
within US.

When meeting in North America, I would strongly prefer cities that
have several direct flight connections from both Europe and Asia.
Of the recent IETF meeting places, San Diego is the only one that
clearly fails this criteria... so why are we going there again?



Even direct flights within the US can be hard to find.

Depending on where you are coming from, and when you purchase your 
tickets,

you may find it faster / cheaper / better
to fly to LAX or Long Beach and drive down to San Diego. (LAX <-> San 
Diego is ~ 200 km, and LAX
is basically on the San Diego Freeway.) I did this for the one San 
Diego IETF.




s/the one San Diego IETF/the one San Diego IETF I attended/

Sorry for the typo
Marshall

If you do that, be aware that there is a permanent immigration 
checkpoint on the

San Diego freeway Northbound, which can cause backups returning.

Regards
Marshall



Best regards,
Pasi

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



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



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





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

Re: RFC Author Count and IPR

[Andy Bierman]

David Harrington wrote:

If I remember correctly, we only limit the number of suthors on the
first page of the document. 


It is perfectly acceptable to list a longer set of names inside the
document in an contributors section.


It's not just the first page.
It also affects the reference citation used in
the RFC Index and all other RFCs.

I believe the 5 author rule was used as justification to remove
most of the original SNMPv2 authors from the author list and all
further reference citations, when the RFC 1901-1909 series was
advanced.  I don't really understand what purpose this serves.




I also have concerns about who should be listed as an "author" and
have copyrights when a work is developed by a WG. The demand to do
things with IETF documents beyond IETF standards work seems to be
growing, so it will be an increasingly difficult problem if we do not
identify all the people who contributed significant portions of a
document (where significant is of course open to debate).


There is a problem with companies piling on the authors
for I-D proposals to make it look like lots of people
worked really hard on it and all agree on the contents.
(This is hardly ever the case.)

Then when you go to WG draft, there are already 5 or 7 names
as authors, and the WG wants to add more.  I think then, you
have to pick a real Editor (responsible for all edits all
the way through AUTH48) and just list that person as Editor
on the first page and citations, and put everybody in
the Authors section in the back.

IMO, this is different than removing the author(s) of a previous
version of an RFC.  I object to that practice.




dbh


Andy

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

Re: About cookies and refreshments cost and abuse

[Andy Bierman]

Stewart Bryant wrote:



In Paris, we switched to a late dinner  which was necessary in Paris
but we did this in Dallas.  Was this a general decision that I missed?
I prefer dinner from 6 - 8 and a night session where the local customs
support this.  This might also cut down the need for afternoon sugar
consumption.


I normally fly in from Europe and strongly prefer the later dinner -
not because I like late dinners - but because I prefer to have the
sessions before I fall asleep with jet lag.


I heard this comment in Dallas from several people.
It works in reverse when I fly to Europe from California.
(I'm ready to start WG meeting at 4am :-)

I think one's opinion of the new schedule has more to
do with whether you had any night sessions to attend
that your country of origin.  If you go to any night
sessions, the old schedule is awful.  If not, you don't
care so much.




- Stewart


Andy


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

Re: Meeting format (Re: Moving from "hosts" to "sponsors")

[Andy Bierman]

Dave Crocker wrote:



(IMO, BOFs should be early in the week, not on Friday.
Cross-area review of new ideas is just as important as
anything else.)



This is an interesting suggestion.

Any meeting that is early in the week gets the benefit of follow-on 
hallways discussions, during the rest of the week.  However BOFs are a 
specific class of meetings that tend to need this more than most.


BOFs are trying to gain interest and even a good BOF will tend to 
engender some fuzziness, with resulting efforts at clarification.  This 
often benefits most from the combinations of smaller discussions that 
are so common during IETF meetings.


It's not just hallway talk.
IETF attendance patterns clearly indicate that
a BOF on Friday will be more lightly attended than on
other days (especially M-W).



d/


Andy


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

Re: Meeting format (Re: Moving from "hosts" to "sponsors")

[Andy Bierman]

Brian E Carpenter wrote:

Andy,

As I hope everybody knows, about 60% of the IASA budget
comes from meeting fees, and we must make enough surplus on
the meetings to fund the secretariat. So, if we did
decide to change the nature of any of our meetings, we'd
really have to understand the budget implications. That being
said, we should certainly explore alternatives to the present
way of doing things. My own experience as a WG chair is that
interim meetings are highly effective when starting out on a
new effort and consensus has to be reached on fundamentals.
I'm less convinced that longer meetings are useful when
refining complex documents - that is when editorial teams
and issue trackers seem to be effective. As I said the other
day, cross-fertilization remains important. It's hard to imagine
how we could run multiple in-depth meetings in parallel
without losing cross-fertilization.

Maybe we could experiment with a meeting with one day (out of
4.5) dedicated to 7 in-depth WG meetings, and the other 3.5
days "traditional"?



This would be great.
If we could get the sponsors who who have paid for
the entire interim meeting costs somewhere else chip in,
the the IETF could extend room and network services until
8 PM Friday, and we could have "Interim Friday".   This
would have the least impact on regular IETF activities.
Since only dedicated people show up to interims anyway,
holding them on Friday won't impact the masses in the slightest.

Of course, you would need volunteer WGs who even want to
have a 1 day interim instead of a 2 hour slot in Montreal.
(NETCONF WG volunteers right now ;-)

(IMO, BOFs should be early in the week, not on Friday.
Cross-area review of new ideas is just as important as
anything else.)



   Brian


Andy



Andy Bierman wrote:

Harald Alvestrand wrote:


Andy Bierman wrote:


Ray Pelletier wrote:


...


A more workable model would be to treat the current
type of meeting as an Annual Plenary, full of Power-Point
laden 2 hour BOFs, and status meetings of almost no value
in the production of standards-track protocols.

The other 2 IETFs would be Working Group Meetings.
Essentially, this as a collection of WG Interim Meetings.
WGs meet for 1-3 days and mash through documents and
get them done fast.  Decisions validated on the WG mailing
list within 2 weeks of IETF Friday.


are you seeing these as meetings of *all* WGs, or do you envision 
multiple meetings, each with some subset of WGs?
If (guesstimate) 50 of 120 WGs decide to meet in this format, the 
number of parallell tracks at one monster meeting will run between 15 
and 30.





There would need to be lots of overlap.  Lots of preparation
for joint-meetings would be needed.  Not everybody
can work on everything at once.  (More accurately, most
people won't be able to read email while ignoring the
meeting in as many WGs. ;-)

Meeting slots would be divided into 3 categories, times, allocations,
and proportions decided by the IESG.

  - WG
  - intra-area
  - inter-area

This might even lead to more shared work, more cross area review,
more consistency. You know -- proper Engineering.

(Maybe we have way too many WGs.
That problem is out of scope here.)


It should take 1 year to get a standards-track RFC out the door.
Not 6+ years.  The solution is obvious.  Quit messing around
and get some work done.   This turtle pace has got to end.
Interim meetings should not be a almost-never way to get
work done.  Any IETF veteran knows it's the only way
anything gets done around here.




I'm intrigued by the idea of replacing one or more IETF meetings with 
"large interims", but would like to work through exactly what's being 
proposed. (Of course, scheduling 2 years out DOES interfere with 
"quick" experiments)




The meeting slot allocation (General Agenda)
is set in stone 30 days in advance of IETF Sunday.
BOF agendas are due 30 days in advance of IETF Sunday.
WG agendas are due 15 days in advance of IETF Sunday.
No exceptions.


and cancellation on those WGs who do not provide such agendas? 
Just checking




Remote audio and jabber for all meetings of course,
and better remote meeting participation tools over time.
If the meeting fees could be lowered over time because
smaller venues are needed 2 out of 3 IETFs, then more
people will be able to participate.

The meeting fee represented 41% of the total cost of
my attendance to IETF 65.  IMO, sponsors at the Plenary
meeting would be appropriate, and could help the IETF
fund a cheaper, more stable, IETF-controlled, conference.


My cost for this meeting (VERY rough, off the top of my head):

- Hotel: 800 dollars
- Food: 400 dollars
- Airfare: 1200 dollars
- Meeting fee: 550 dollars
- Misc: 50 dollars

Total: 3000 dollars. Meeting fee percentage: 18%.
But we've been around the "how much does the meeting fee matter" bush 
before.



Next time I go to Europe instead of US, ou

Re: Moving from "hosts" to "sponsors"

[Andy Bierman]

Henning Schulzrinne wrote:

Indeed. Not only is it small, it isn't where corporate bean counters
put their attention, which is air fare, hotel, and per diem.


Brian,

this is not universally true. With cheaper air fares and not staying in 
the overpriced Hilton hotel rooms, my IETF65 meeting fee was almost 
exactly the same as my combined hotel and air fare costs. For those of 
us not on corporate expense accounts, it's the total amount that matters.



Sometimes, people even use frequent flier miles, double up
in rooms, and don't eat every meal in an over-priced restaurant,
just to attend an IETF.  (Not me, but some people ;-)

For people paying their own way, the meeting fee is the only
fixed cost in the trip.  It's expensive already, and trending
upwards (not expensive if you stay all 5 days, but some of us don't).

I guess I was just wishing out loud when I said maybe the
meeting fee could trend down instead of up.  I would be happy
if the IETF had more control over the meetings so the fees
were stable, the network was stable (use sponsor money to
buy more gear and let our ace NOC team control it), and
the venues were set far enough in advance to give me
the maximum travel options.

The old single sponsor system isn't working anymore.
I'm concerned the IETF will fix the problem by raising
the meeting fee $50 every 6 months.


Andy


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

Re: 2 hour meetings

[Andy Bierman]

Edward Lewis wrote:

At 15:51 +0100 3/25/06, Brian E Carpenter wrote:


If somebody comes to the IETF for a two hour meeting and wastes
the opportunity of another 30+ hours of learning about what other
WGs and BOFs are up to, that would indeed be a shame.


I agree with this, but find that (in some instances) that meetings are 
run counter to this goal.


I sat in an session outside my area of experience and heard this from 
the first speaker, "if you haven't read the drafts, you shouldn't 
participate here.  Therefore I will not have slides and dive into the 
details."  As this was outside my area of experience, I had not taken 
the time to read up on the session. I figured that having scribed for it 
at the previous meeting would give me enough cover.


Before each speaker in that session, the question "who has read" was 
asked, with few hands going up each time.  It would be far more helpful 
to try to be "inclusive" rather than "exclusive" towards us tourists.


If the IETF wants to foster cross-fertilization, which is the reason for 
the mass enclaves, then temper the theme of "you must have read all the 
drafts."  Temper, not "remove."  Taking a few moments to set the problem 
up for the uninitiated and then assuming they have the protocol 
engineering smarts is all I'm asking.





IMO, the purpose of a Working Group meeting is to gather
people together to work.  If 40 out of 45 people come to
the meeting totally unprepared to work on the stated agenda,
then don't be surprised if you don't get any work done.
The purpose is not to explain the entire draft to tourists
with slideware.

If the purpose of all our face to face meetings is to foster
cross-area review and not for WGs to get any work done, then
I guess this is not a problem.  IMO, 1 out of 3 of these
non-work-oriented meetings would be plenty, and 3 out of 3
is clearly harming productivity.


Andy


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

Re: 2 hour meetings

[Andy Bierman]

Brian E Carpenter wrote:

Thanks to Keith for changing the Subject when changing the subject.


I know you've heard this all before, but it's been getting
increasingly difficult for us WG Chairs to get all the key
people working on a protocol to fly across the planet for
a 2 hour meeting.  These are busy people who can't
afford to block out an entire week because they don't
know when or where the 2 hour meeting is going to be.
(This even applies to some WG Chairs ;-)


Andy, you've heard _this_ before, I'm sure: the reason we do IETF
weeks with many WGs in one place is to foster cross-fertilization,
and to strongly encourage people to become aware of work in
other WGs and other Areas that may impact their own topic.
There are very few cases of WGs that can safely work in isolation
from the rest of the IETF. We're all busy, but missing out on
what's happening elsewhere is a good recipe for getting unpleasant
late surprises when a draft finally gets a cross-area review.

If somebody comes to the IETF for a two hour meeting and wastes
the opportunity of another 30+ hours of learning about what other
WGs and BOFs are up to, that would indeed be a shame.



I understand that is a goal of IETF participation for some people.
IMO, the people who can help the most on development of a
particular protocol are not doing that.

The current solution is for progress-conscious WGs to hold interim
meetings, which seem to be discouraged, and certainly increase
travel cost for most to participate.

I do not envision a WG Interim IETF to be a regular IETF,
except people read email all day in 1 WG instead of 5.

Cross-area review is a reactive process.  A cross-area interim
design meeting is a proactive process, that encourages better
design reuse, consistency, and robustness.  I think some
joint-WG interims, intra-area planned project development
meetings, inter-area interims are important.  The IESG
would need to prioritize the meeting slot usage as always.

It would be awesome if the key people to answer
an unexpected question that comes up in an interim just
happen to be in the building for a different interim.
We would get much more cross-area review in the design phase,
where it does the most good.

We could have every 3rd or 4th IETF be work-focused instead
of cross-review focused.  We could try it once.  Or we could
do nothing and just accept the slow pace of progress, and
the cost of WG interim meetings.





Brian


Andy


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

Re: Meeting format (Re: Moving from "hosts" to "sponsors")

[Andy Bierman]

Harald Alvestrand wrote:

Andy Bierman wrote:

Ray Pelletier wrote:

...

A more workable model would be to treat the current
type of meeting as an Annual Plenary, full of Power-Point
laden 2 hour BOFs, and status meetings of almost no value
in the production of standards-track protocols.

The other 2 IETFs would be Working Group Meetings.
Essentially, this as a collection of WG Interim Meetings.
WGs meet for 1-3 days and mash through documents and
get them done fast.  Decisions validated on the WG mailing
list within 2 weeks of IETF Friday.
are you seeing these as meetings of *all* WGs, or do you envision 
multiple meetings, each with some subset of WGs?
If (guesstimate) 50 of 120 WGs decide to meet in this format, the number 
of parallell tracks at one monster meeting will run between 15 and 30.





There would need to be lots of overlap.  Lots of preparation
for joint-meetings would be needed.  Not everybody
can work on everything at once.  (More accurately, most
people won't be able to read email while ignoring the
meeting in as many WGs. ;-)

Meeting slots would be divided into 3 categories, times, allocations,
and proportions decided by the IESG.

  - WG
  - intra-area
  - inter-area

This might even lead to more shared work, more cross area review,
more consistency. You know -- proper Engineering.

(Maybe we have way too many WGs.
That problem is out of scope here.)


It should take 1 year to get a standards-track RFC out the door.
Not 6+ years.  The solution is obvious.  Quit messing around
and get some work done.   This turtle pace has got to end.
Interim meetings should not be a almost-never way to get
work done.  Any IETF veteran knows it's the only way
anything gets done around here.




I'm intrigued by the idea of replacing one or more IETF meetings with 
"large interims", but would like to work through exactly what's being 
proposed. (Of course, scheduling 2 years out DOES interfere with "quick" 
experiments)


The meeting slot allocation (General Agenda)
is set in stone 30 days in advance of IETF Sunday.
BOF agendas are due 30 days in advance of IETF Sunday.
WG agendas are due 15 days in advance of IETF Sunday.
No exceptions.
and cancellation on those WGs who do not provide such agendas? Just 
checking


Remote audio and jabber for all meetings of course,
and better remote meeting participation tools over time.
If the meeting fees could be lowered over time because
smaller venues are needed 2 out of 3 IETFs, then more
people will be able to participate.

The meeting fee represented 41% of the total cost of
my attendance to IETF 65.  IMO, sponsors at the Plenary
meeting would be appropriate, and could help the IETF
fund a cheaper, more stable, IETF-controlled, conference.

My cost for this meeting (VERY rough, off the top of my head):

- Hotel: 800 dollars
- Food: 400 dollars
- Airfare: 1200 dollars
- Meeting fee: 550 dollars
- Misc: 50 dollars

Total: 3000 dollars. Meeting fee percentage: 18%.
But we've been around the "how much does the meeting fee matter" bush 
before.


Next time I go to Europe instead of US, our expense ratios
will be reversed.  These 2 data points aren't meaningful.



Cheaper is better, and how much it matters varies widely between people.

   Harald



Andy

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

Re: Moving from "hosts" to "sponsors"

[Andy Bierman]

Ray Pelletier wrote:



Andy Bierman wrote:


JORDI PALET MARTINEZ wrote:

I don't think the meeting fees could actually go down, may be more in 
the

other way around if we are realistic with the cost figures.

Actually the cost is already high for a sponsor, and I believe trying 
to get
more from the industry (or other kind of sponsors) for each meeting 
will be

really difficult.




IMO, the current trend and situation is not sustainable.
It may be fine for professional standards attenders, but
I'm trying to get some people to show up in my WG who
actually write code and run networks for a living.
They don't want to come here anymore.


What changes would have to be made so that they would want to attend?


my $0.02:

Nothing -- not in the current meeting format.

A more workable model would be to treat the current
type of meeting as an Annual Plenary, full of Power-Point
laden 2 hour BOFs, and status meetings of almost no value
in the production of standards-track protocols.

The other 2 IETFs would be Working Group Meetings.
Essentially, this as a collection of WG Interim Meetings.
WGs meet for 1-3 days and mash through documents and
get them done fast.  Decisions validated on the WG mailing
list within 2 weeks of IETF Friday.

The meeting slot allocation (General Agenda)
is set in stone 30 days in advance of IETF Sunday.
BOF agendas are due 30 days in advance of IETF Sunday.
WG agendas are due 15 days in advance of IETF Sunday.
No exceptions.

Remote audio and jabber for all meetings of course,
and better remote meeting participation tools over time.
If the meeting fees could be lowered over time because
smaller venues are needed 2 out of 3 IETFs, then more
people will be able to participate.

The meeting fee represented 41% of the total cost of
my attendance to IETF 65.  IMO, sponsors at the Plenary
meeting would be appropriate, and could help the IETF
fund a cheaper, more stable, IETF-controlled, conference.



Ray


Andy

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

Re: Moving from "hosts" to "sponsors"

[Andy Bierman]

JORDI PALET MARTINEZ wrote:

I don't think the meeting fees could actually go down, may be more in the
other way around if we are realistic with the cost figures.

Actually the cost is already high for a sponsor, and I believe trying to get
more from the industry (or other kind of sponsors) for each meeting will be
really difficult.



IMO, the current trend and situation is not sustainable.
It may be fine for professional standards attenders, but
I'm trying to get some people to show up in my WG who
actually write code and run networks for a living.
They don't want to come here anymore.




Regards,
Jordi





Andy



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

Re: Moving from "hosts" to "sponsors"

[Andy Bierman]

Marshall Eubanks wrote:
I think that the IETF neglects (or, rather, has neglected in the past) 
many possible

opportunities for sponsorship. That implies that increasing the income
from sponsorship should be possible.

People who are concerned with this issue should talk (or email) our IAD, 
Ray Pelletier, who

has a number of ideas in this area (and who reads this list).
If people feel that some sorts of sponsorship are not
appropriate, I am sure that Ray would like that input too.

In the new IASA / NeuStar system, there is no choice but to be realistic 
with

cost figures. Note that the registration fee and the attendance both went
up with this meeting, which of course means that revenue increased. I 
actually think

that, with revenue and sponsorship both increasing, the IETF should be
able to improve the meeting support and experience even more in the future.




I know you've heard this all before, but it's been getting
increasingly difficult for us WG Chairs to get all the key
people working on a protocol to fly across the planet for
a 2 hour meeting.  These are busy people who can't
afford to block out an entire week because they don't
know when or where the 2 hour meeting is going to be.
(This even applies to some WG Chairs ;-)

I would support any plan that will make meetings cheaper
and easier to attend for everybody.  I'd like quick action,
not a 2 year study to think about it.




Regards
Marshall


Andy

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

Re: Moving from "hosts" to "sponsors"

[Andy Bierman]

Dave Crocker wrote:

Michael StJohns wrote:
What I think Jordi is saying is that he wants the US sponsors to 
subsidize the cost of the overseas meetings.  At least that's what it 
works out to be


This view can be mapped to a classic model that would have significant 
benefits for the IETF:



A "host" gets all sorts of marketing leverage out of the role in 
producing an IETF.


There is nothing that requires that the event site management effort be 
coupled with a particular host's venue.


If we moved to a model of having companies provide sponsorship funds, in 
return for which they get appropriate marketing presence, then we could 
have meeting venue management move to the sort of predictable and timely 
basis -- ie, far enough ahead of time -- that has been a concern for 
many years.



Amen!  And maybe the meeting fees could actually go down
with enough sponsors.  An additional room like the terminal
room (not out in the open) could be used.


Also, the IETF could maintain control of the
network if there were multiple sponsors instead
of a single host.   They would not be allowed to ignore
the advice of the NOC team, and let the wireless meltdown
right off the bat.






d/




Andy


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

Re: Guidance needed on well known ports

[Andy Bierman]

Stephane Bortzmeyer wrote:

On Sun, Mar 19, 2006 at 12:42:17PM -0800,
 Ned Freed <[EMAIL PROTECTED]> wrote 
 a message of 35 lines which said:


  

The privileged port concept has some marginal utility on multiuser
systems where you don't Joe-random-user to grab some port for a well
known service.



"had", not "has". The concept was invented at a time where multi-users
machines were rare and expensive monsters. So, a request coming from
source port 513 probably was "serious". Today, any highschool student
is root on his PC and therefore this protection is almost useless.
  


But does that student have access to the root account on servers which
are part of the networking infrastructure?   Who cares if Joe User
blows up his own config. on a PC that nobody else depends on but Joe?

I find the argument flawed -- that because Joe User can be root on his 
own PC,

the concept of privileged access to shared system-critical infrastructure is
somehow obsolete.

Andy




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


  



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

Re: "too many notes" -- a modest proposal

[Andy Bierman]

Anthony G. Atkielski wrote:


Andy Bierman writes:

 


I think you missed my point.
I should have said "enforce or abide by draconian rules".
Automating the process is even worse.
Then stupid scripts disrupt WG activity on a regular basis.
Inappropriate mailing list use should be dealt with by the
WG Chair(s) in a more diplomatic manner.
   



Well, one option is to stop trying to restrict access to lists to
begin with.  The problem with having a human being make the decision
is that human beings are notoriously biased.
 



If we did this, our mailing lists would be bombarded with SPAM
from non-subscribers. 


There is an appeals process (of that we are too painfully aware)
that can be used for people who are told by a WG Chair that
they are using the mailing list in an inappropriate manner, and still
insist on continuing their behavior.

I have found that only the worst managers deal with
bad apples by burdening the entire group with oppressive rules.

Andy


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

Re: "too many notes" -- a modest proposal

[Andy Bierman]

Anthony G. Atkielski wrote:


Andy Bierman writes:

 


I do not share your regulatory zeal.
As a WG Chair and WG participant, I have enough rules to follow already.
The last thing I want to do is count messages and bytes, and enforce
draconian rules like this.
   



But counting messages and bytes happens to be something that can be
easily automated, and it can be applied with absolute consistency to
everyone, without prejudice.  Of course, those are exactly the reasons
why many people would reject the idea--they want to keep other people
from posting, but they also fear being prevented from posting
themselves.
 



I think you missed my point.
I should have said "enforce or abide by draconian rules".
Automating the process is even worse.
Then stupid scripts disrupt WG activity on a regular basis.
Inappropriate mailing list use should be dealt with by the
WG Chair(s) in a more diplomatic manner. 



Andy



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


 




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

Re: "too many notes" -- a modest proposal

[Andy Bierman]

Steve Silverman wrote:


It seems to me that limiting users to 3 messages / day (perhaps with a
maximum number of bytes) would be a
minimal impact on free speech but would limit the damage done by
overly productive transmitters. This could be limited to users  who
are nominated to a "limit" list by many users.  How difficult this
would be to implement on the message exploders is another question.

 



I do not share your regulatory zeal.
As a WG Chair and WG participant, I have enough rules to follow already.
The last thing I want to do is count messages and bytes, and enforce
draconian rules like this.



Steve Silverman
 



Andy

 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Michael Thomas
Sent: Wednesday, January 25, 2006 3:26 PM
To: IETF Discussion
Subject: "too many notes" -- a modest proposal


It seems to me that a lot of what causes working group lists to
melt down is simply the volume of traffic -- usually with plenty
of off-topic banter, or exchanges of dubious value, with
the resulting
conjestive collapse of our wetware buffering. On good days, the
drop algorithm may be more sophisticated than tail drops; on
bad days...

Perhaps we should take a lesson from TCP and set a receive window
on IETF mailing lists in the face of conjestion. The sender is thus
obligated to keep the transmission within the window, and as a side
effect to consider the quality of the, um, quantity. Just
this simple
step would greatly limit (purposeful) DOS attacks and other death
spirals. It also mitigates the "free speech" attacks by not
throttling
based on content (which is inherently contentious), but based on
wg mailing list "bandwidth".

in all modesty, Mike

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

   




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


 




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

Re: Working Group chartering

[Andy Bierman]

Burger, Eric wrote:


IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
We then spend tons of resources on figuring out if the idea will work.
We produce lots of half-baked documents with little basis in working
code.  Then folks try implementing what's been spec'ed, find it doesn't
work, but then find a ton of resistance to change, because the specs are
three years old and "we don't want to break draft-mumble-05
implementations."
 



I completely agree with you.
I wonder if we are in the minority opinion?
Standardize stuff that already works -- what a concept.

When we see a proposal without any "running code"
to back it up, we should be asking:
"If this is so good, then why aren't you using it yourself?"


If something is an idea, let's make it politically acceptable for the
"work" to be done in the I*R*TF first.

 



I don't care how the technology gets developed.
IRTF, vendors, universities, whatever.  Show us
running code that's reasonably close to what you
want to standardize.  Let's get feedback from people who
have used the technology, too.



Yes, I agree that the process should be fuzzy - the AD should be able to
figure out if something is likely to work in the real world.  However,
building a work group out of an idea, rather than somewhat working code
or a demonstration framework, should be the exception, rather than the
rule. 
 



Agreed, but I'm no fan of more process rules.
Area Directors who want to produce successful standards
will know how to make this decision.  ADs have to be tough
enough to say "Come back when you've done more work."


Andy


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dave Crocker
Sent: Tuesday, January 03, 2006 1:13 PM
To: Jeffrey Hutzelman
Cc: ietf@ietf.org
Subject: Working Group chartering

[snip]

And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an
idea.  Some with a detailed proposal.  Some with a detailed
specification and some with existing and deployed technology.  When a
working group starts, it must make the strategic decision about how much
prior work to preserve, versus how much new work to encourage or
require.
[snip]

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


 




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

Re: jabber rooms

[Andy Bierman]

Brian E Carpenter wrote:


I don't think I've seen a reminder this week that
jabber room for the XXX WG or BOF is

   [EMAIL PROTECTED]



FYI:

Audio feed info:
http://videolab.uoregon.edu/events/ietf/

Jabber info:
http://www.xmpp.org/ietf-chat.html

Meeting slides:
https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64


Andy


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

Re: Where can I find capwap BOF Agenda ?

[Andy Bierman]

At 05:44 PM 7/1/2003, Soohong Daniel Park wrote:
>Hi all
>
>I am searching for capwap Agenda

http://www.ietf.org/ietf/03jul/capwap.txt


>Friday, July 18
>OPS  capwap  Control And Provisioning of Wirelsss Acc. Point BOF
>
>
>
>Daniel (Soohong Daniel Park)
>Mobile Platform Lab,SAMSUNG Electronics

Andy

Re: Financial state of the IETF - to be presented Wednesday

[Andy Bierman]

At 03:20 PM 3/15/2003 -0500, Melinda Shore wrote:
>> My guess is that going to two would hurt income, unless we raise fees by 
>> 50% - the same people would come, I think.
>> Going to four would be damaging to my sanity, at least - don't know about 
>> others' we whould expect slightly lower per-meeting attendance, but 
>> many would indeed feel obligated to go to all four, so would pay more, I 
>> think. Whether they would get more things done is an open question.
>
>I hate the idea of more travel, plus I suspect 4 may be
>harder to justify to management.  However, try as we may to
>do things "right," the IETF is increasingly doing its work
>at meetings instead of mailing lists.  If we can't fix it we
>should probably accept it.  Also, more regular meetings
>might tend to discourage interim meetings, which would be
>excellent.

I agree.  Given that the work of the IETF is centered on the
publication of documents, and given that most I-Ds are published
near the I-D cutoff deadlines, it stands to reason that IETF
productivity will increase by 33% if the number of publication 
cycles per year is increased from 3 to 4.


>Melinda

Andy

Re: Splitting the IETF list

[Andy Bierman]

At 09:29 AM 11/19/2001 +0100, Brian E Carpenter wrote:
>Andy,
>
>I don't see how this will help. The nonsense messages will still come,
>from the usual sources, often copied to both lists, which will only
>increase the level of annoyance.


IETF Last Call is a critical part of the Standards Process.
It's our last chance to do a cross-domain sanity check on
new technology, and give this input to the IESG, before
they decide to approve a standard or not.

These critical emails comprise less than 1 percent of
the traffic on the IETF list. (My unscientific survey says...)
I wouldn't characterize the other 99% as pure noise, maybe just 95%.

I know of several longtime IETFers who ignore this list because
of S/N ratio is so bad.  If there was a [EMAIL PROTECTED] mailing list,
more people might make Last Call comments.  People who
post off-topic messages will be shouted off the list and
if they keep doing it, they will be blocked from posting.

Andy




>[Splitting the -announce list doesn't have this disadvantage.]
>
>   Brian
>
>Andy Bierman wrote:
>>
>> Hi,
>>
>> I would like the IESG to consider splitting this list into 2 lists.
>> One list for discussion of Last Call issues and another for
>> everything else (including minor stuff like splitting the
>> IETF-Announce or IETF lists :-)
>>
>> thanks,
>> Andy

Splitting the IETF list

[Andy Bierman]

Hi,

I would like the IESG to consider splitting this list into 2 lists.
One list for discussion of Last Call issues and another for
everything else (including minor stuff like splitting the
IETF-Announce or IETF lists :-)

thanks,
Andy

[Fwd: RMONMIB WG interim meeting announcement]

[Andy Bierman]

 


Hi,

The RMONMIB WG intends to hold an interim meeting to
work on all aspects of the new charter. This includes:
  - Application Performance Monitoring (APM)
  - Transport Performance Metrics (TPM)
  - User-Defined TopN Monitoring MIB (UsrTopN)
  - DIFFSERV Monitoring MIB (DS-MON)

Meeting Dates: 
   Monday, May 15 9am - 6pm
   Tuesday, May 16 9am - 6pm

Location:
   (Meeting Site TBD)
   San Francisco or San Jose, CA

Sponsor:
   A sponsor or co-sponsors are needed to host this meeting.
   A hotel meeting room is preferred, but corporate facilities
   will be good enough. Please contact me at [EMAIL PROTECTED]
   if you can help.