Hi Tom,
Thanks for you good feedback. Please see some comments inline.
On 26. Feb 2020, at 13:00, tom petch <daedulus@xxxxxxxxxxxxx> wrote:
I think that this I-D needs more work. It is too lax.
It asks that the original assignee and contact be preserved as a Note; I disagree - I think that they should be in columns entitled Original Assignee or some such and that the IANA registry be updated with a reference to this I-D as an RFC so as to see what happened.
I had this idea as well but as Paul also commented, the idea was to leave the decision on how to maintain the registry rather to IANA. So I might actually rather update to be less concrete here.
It calls for action if the e-mail address is not valid. What does this mean? It needs to be more specific, such as there is no MTA for the domain, or the MTA says that there is no such local part.
This shades into the third call for action, 'do not show success within 4 weeks'. What is success? You need to specify actions for e-mail valid but no reply, e-mail valid but a non-response (e.g. I am currently out of the office) as opposed to 'yes, I am fine with what you propose' and 'No I do not consent'. Others may think of other actions that need different actions.
The idea here really is that IANA will report to the IESG after 4 weeks. Of course the assumption is that IANA will also tell why the action was not successful (with all possible reasons you mentioned above) and then the IESG might take further actions.
Then there is the question of what the enquiring e-mail should contain. At the very least, it should reference this RFC to be so that the recipient, who may have had no contact with the IETF for years, knows what is being asked and should summarise what has been requested and why so that those who do not want all the detail of the RFC to be can understand what is being asked of them and why.
If you look at the -00 draft version, there was proposed text, however, again on request of IANA we took this out in order to give more room to IANA to do the right thing. I understand that phrasing this email correctly can be critical and I would expect IANA to coordinate with the IESG before sending something out.
Where there is no reply, or a refusal, then I think that an IETF list should be notified so that the collective wisdom of the IETF can be invoked.
If there is agreement to release the port, the IESG could decide to still change some existing entries if that is seen as critical. In this case those changes would be implemented based on IEGS Approval which should go inline with "call for comments", as stated in section 4.1 of rfc5226. I guess that could be stated more clearly in the draft.
Comparable exercises have been done in the past and they needed careful attention to details such as this.
Yes, again thanks for you good feedback!
I also see a number of unusual spelligns but they can weight.
Yes, I also was a bit in hurry with the last update. I also have a working version with a couple of them fixed.
