[arch-d] Comments on draft-iab-protocol-maintenance-03

[S Moonesamy <[e-mail]>]

Hi Martin,

I have a few comments on draft-iab-protocol-maintenance-03.  I like 
the draft as it offers a challenging view of a principle stated by 
the IAB.  I do not agree to its argument against the robustness principle.

How can one determine whether critical details have been omitted 
(Section 3) when the protocol designer interacts with the 
implementer?  The specification may be clear to the reviewer as what 
he/she considers as obvious might be viewed as a critical detail by 
someone who does not regularly follow IETF discussions.  The 
problematic parts of a protocol can only be identified through 
feedback.  In the IETF, this is usually done through an 
erratum.  According to one of the examples given in the draft the 
protocol maintenance took eight years.  Why weren't the specification 
shortcomings addressed within a few years after publication?

Fatal conditions (Section 3) can cause a product failure.  One of the 
issues is getting two or more parties to agree on who is responsible 
for fixing the fatal condition.  It is simpler to reduce the 
likelihood of a failure in comparison with convincing the protocol 
designer or the implementer to fix the issue.

It is difficult to get approval for a protocol change (Section 4) as 
there is very little interest in revisiting the specification once it 
has been published.

The draft mentions the ecosystem (Section 4).  Is there a 
relationship between interoperability and competition [1][2] in the ecosystem?

What would be the impact if every piece of software had telemetry 
built in (Section 7.1)?  Shouldn't those errors be caught during 
testing instead of the software collecting information globally?

As an overall comment, the protocol examples in the draft are mainly 
web related.  How does protocol maintenance work in other areas?  Was 
interoperability [3] more of an advantage instead of a disadvantage?

Regards,
S. Moonesamy

1. 
https://warwick.ac.uk/fac/soc/economics/research/workingpapers/2010/twerp_924.pdf
2. http://ec.europa.eu/competition/publications/reports/kd0419345enn.pdf
3. 
https://blog.mozilla.org/netpolicy/files/2018/08/Mozilla-FTC-filing-8- 
20-2018.pdf