Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48

[Iván Arce <[e-mail]>]

Hi Suresh

Thanks for your clarifications, I've commented them below

El 22/2/17 a las 13:01, Suresh Krishnan escribió:
> Hi Iván, I would like to clarify a few things here
> 
> a) It is not about the text, it is about the timing. This was done in
> AUTH48 where all the authors need to approve the changes.

I beg to differ. I believe this is both about the timing AND about the
content.

Had the acknowledgments been to an IETF elder of the tribe, a regular of
the 6man mailing list or some random university or government
organization I seriously doubt anybody would have objected them. To me
at least, it is evident that what triggered the objection was not the
timing but the content of the acknowledgements.

In any case, even if it wasn't about it, the fact that the "not
technically substantive" content was quoted verbatim in the call for
support/not support *made it* about the content and not about the
timing. The message below seem to be about the text not the timing:

  "Some of the other authors don’t think this change is appropriate
   for  AUTH48, but the author proposing this has insisted on adding
   this text.
   Please respond with either support or non-support for this proposed
   change by 18 February 2017."

With regards to the timing, I agree that according to all existing data
I've found, including the documents I cited, all authors need to approve
changes in AUTH48. But it is also truth that the document that describes
AUTH48 also says that the document should get OK from the AD, WG chair
IF the changes introduced in AUTH48 are "technically substantive" or
"too extensive".

That condition is not met here.

The matter has been exposed to a process that is not stated anywhere and
that, in my opinion, was unnecessary, discretionary and wrong.

Unnecessary because it could have been addressed directly by the RFC
editor with or without the authors involvement.

Discretionary because, and we seem to agree on this, there was no
previously stated procedure to follow in a case like this and the case
was handle in an ad hoc fashion.

And wrong because, in my opinion of course, setting precedent of seeking
WG consensus for striking down (or not) text in the Acknowledgements
section of an RFC signals an overly zealous stance on a technically
irrelevant matter.

> 
> b) Your comments about RFC1812 and April 1st RFCs are not relevant
> here because they are not equivalent.

Indeed, they are not equivalent but that does not make them irrelevant.
You just chose to dismiss the comments on the basis of a lack of
equivalence.  My intention was to point out that there is a tradition of
being lenient, joyful and flexible on certain content. But hey, its
okay, I am not planning to engage in a contest of nitpickery over this.


> c) The reason you don’t find authoritative guidance for everything is
> because we either have not seen the situation before or it does not
> happen frequently enough to warrant making up process for it.

I wasn't looking authoritative guidance for everything, I was looking
authoritative guidance *specifically* for this. You are confirming that
there is none and that this is quite an infrequent situation. It would
have been great if somebody could recollect a similar situation that
could be used for comparison or guidance.

> Checking with the WG was a common sense decision for a WG document.

There is nothing of common sense in checking with the WG about not
"technically substantive" nor "too extensive" changes.

Come on, these were an author's personal acknowledgements. You can
rationalize this as much as you want, I am not going be to convinced and
we can all live with that.


> The only other solution that would have been fair is to let the
> document sit around in AUTH48 until the authors converged. This was
> not a realistic option for me since I am holding another document
> (RFC-to-be-8065) due to a reference to this document. So, if you
> think that you have a fair and expedient solution that is different,
> please feel free to propose it. I am all for learning and improving.


I have already proposed it

Be flexible, be liberal in what you accept, let the text stand on this
one, publish it as is, take note for the future, provide future guidance
to authors.

If you want to codify what the Acknowledgements section should say or
what changes added in AUTH48 that aren't "technically substantive" nor
"too extensive" require AD or WG approval when authors don't converge on
the final text...

write a draft :)

Frankly I don't have much more to say about this topic, I've already
posted one message more than I originally intended. this one is the last
one.

thanks for your time

regards,

-ivan


-- 
Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
http://www.fundacionsadosky.org.ar
TE: ([phone]
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E