Hiya, On 05/02/2020 23:51, Michael StJohns wrote:On 2/5/2020 6:30 PM, Stephen Farrell wroteI 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
