Re: [arch-d] [Last-Call] Call for Comment: <draft-iab-for-the-users-02> (The Internet is for End Users)

[Michael StJohns <[e-mail]>]

On 2/5/2020 7:01 PM, Stephen Farrell wrote:
> Hiya,
>
> On 05/02/2020 23:51, Michael StJohns wrote:
>> On 2/5/2020 6:30 PM, Stephen Farrell wrote
>>> I don't recall other documents being as formal as that about it,
>>> but sure, if/when the IAB decide to publish this after community
>>> comment then it could be clearer that it's an IAB document, e.g. by
>>> having Mark as editor as you suggest. That it is an IAB document
>>> seems fairly clear to me from the filename and from the IAB
>>> adoption call etc. that was sent to this list back last June/July,
>>> but I guess that's a while back.
>> Um.. yes, I know it's an IAB stream document - which does not
>> necessarily imply that it is a consensus document of the entire IAB.>
>> And going back and re-reading the announcement, it looks too much
>> like a last call request rather than a call for "help us make the
>> document better".    I'm not sure why anyone would assume that the
>> IAB hadn't yet decided to publish it or something very like it.
> Well, to be fair, there was a public call for comment
> before the IAB adopted this.

OK - then you're NOT asking for discussion on whether to publish?  :-)   
No worries - I can work with either.


>
>> As far as I can tell from the published RFC's - documents that
>> represent IAB consensus on a policy matter are mostly published as
>> "Editor"Â  and have something that identifies how you got there: E.g.
>> RFC8558 had Ted as editor and included this in the status:
>>
>>> This document is a product of the Internet Architecture Board
>>> (IAB) and represents information that the IAB has deemed valuable
>>> to provide for permanent record.  It represents the consensus of
>>> the Internet Architecture Board (IAB).  Documents approved for
>>> publication by the IAB are not candidates for any level of
>>> Internet Standard; see Section 2 of RFC 7841.
>> Documents that are more "spec"ish (i.e. the RFC v3 format) either
>> have an editor or a technical expert as the author.   And even then
>> you get the same statement - see RFC8546 and 8700
>>
>> Those are the last three IAB stream documents published.   Going
>> back further a "tech"ish document omitted the "Consensus of the IAB"
>> statement - RFC6574 - simply a report from a workshop.
>>
>> That being said, these are all statements in the status section
>> which will be different from the ID to the RFC.
> Yep, the above seems (to me) like a good comment that could
> be handled without having to invent some new strict process
> for IAB stream document boilerplate - I'd hope that some
> variation in how these things are presented/worded is ok.

I think that it needs to be brought forward to the ID in some form - or 
it needs to be included in the call for comments. Somewhere before the 
RFC editor gets it.


>
>> It would be
>> useful for a policy document (I use the term "policy" loosely here)
>> to have that consensus statement be made somewhere.  Mostly in other
>> documents its pretty clear how we got there - some event, some
>> workshop, some question asked at a plenary that's being answered.
>>
>> Here - I'm not sure what triggered the IAB into writing it and
>> worse, I'm not sure what affect you want it to have on the formal
>> IETF processes.  Context would be good, actionable recommendations
>> would be better.
> That (the question of effects) seems like a separate
> point. Surely section 4 of the draft is all about
> actionable recommendations though so I'm a bit confused
> as to what you mean?

The key word is "actionable".    I went back and re-read section 4 and 
what I got was aspirational rather than actionable.

4.1. comes closest to actionable with the "hold a co-located workshop" 
comment.  And even that is kind of weak.  More along the lines of "To 
husband this process of getting community buy-in we've asked ISOC to 
work with us to create workshops for the next N ISOC meetings with each 
of those workshops targeted at one of these communities.  The IAB will 
provide an overview of the IETF process, near future architecture 
changes and challenges, and how non-participation by that community 
might result in an architecture which does not meet their needs.   We 
will then solicit involvement in an IAB sponsored workshop retreat whose 
output shall be a community centric set of guidelines that will be 
presented to the IETF community for possible inclusion in the standards 
process" -  or something like that.

I have no idea of what "We should also create explicit...." means in 
section 4.2.    If feels like a bit of a non sequitur here.  In any 
event, browsers are not protocols.  The underlying protocols evolved to 
meet functional and the browsers evolved GUI needs. Discussing HTTP and 
HTML evolution rather than browsers in this section might be more 
appropriate and more on point for the IETF. Then we can talk about how 
that maps to the IOT space and what we/IAB/IETF can do about it.

In 4.3 "Negative impact on users" not being defined limits defining 
useful actions.   At least consider how you might measure those impacts 
in a relatively objective way.  Maybe reach out to someone like KC for 
help in identifying ways to do those measurements.   If it can't be 
measured, then it's going to revert to politics and money.

4.4 seems to be a restatement of the Prisoner's dilemma problem in some 
form.    E.g. how do you identify and balance costs to entities that 
might not have any reason to cooperate?

4.5 mostly deprioritizes the value of the work product of the standards 
writers vs the "needs of end users".  Basically, this doesn't meet the 
financial needs test.  Unless you're having the end users compensate the 
writers/implementers in some manner, there is little incentive to put 
their needs ahead of the writers.   At best, you can say that when 
choosing between two equally costly choices, you should pick the one 
that least impacts the end user - again - if you can identify that impact.


Later, Mike



>
> Cheers,
> S.
>
>> Later, Mike
>>
>>
>>
>>
>>
>>