Hi Barry,
Thanks for the explanation. It make sense to me.
I hope that the document will help with getting better defined registries in
the future.
Maybe we can present this document, once it is done, at one of the WG chairs
lunches at the IETF meeting
Roni
-----Original Message-----
From: barryleiba(_at_)gmail(_dot_)com
[mailto:barryleiba(_at_)gmail(_dot_)com] On Behalf Of
Barry Leiba
Sent: Friday, May 27, 2016 5:34 PM
To: Roni Even
Cc: General Area Review Team; draft-leiba-cotton-iana-
5226bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; IETF discussion list
Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
I think that there should be normative language to the IESG to verify
consistency
In principle, I agree with you, but there are practical considerations.
First, I'm pretty sure we don't have IETF consensus to say that working
groups MUST carefully consider the registration policies, coordinate them
among similar/related registries, and write justifications for their
decisions...
and I think we'd have a hard time getting consensus for that. I think the
document does the best we can here, which is to explain why it's important,
and to say that this (English-word)should be done.
Second, few ADs have the interest in being rigorous about this, when they
consider the time spent looking at it, looking at other registries, and
arguing
the point, and considering the other things they're spending their time on
(such as making sure the protocols themselves are solid, that the security
aspects are right, and so on).
When I was on the IESG, I did make a point of challenging working groups on
this point: please show me where the policy was discussed on the mailing list,
and please explain why you settled on Standards Action, and why IETF
Review or even Specification Required doesn't work as well or better.
Sometimes that resulted in changes, and sometimes it resulted in reasonable
explanations and no change. But it took time to do that, and I think we can't
expect it to happen in general.
Third, while there is, as you point out, actual damage done by overly strict
policies (and I do point this out in the new text in the document), the damage
is limited and infrequent for the most part. A few times, we've run into
major issues with very active registries (media types and port numbers come
to mind), and we've put out extensive documents that corrected those
situations. But trying to put MUSTs (whether they be capitalized or not) into
a BCP to avoid those is probably too much, and is not likely to get consensus.
Barry
-----Original Message-----
From: barryleiba(_at_)gmail(_dot_)com
[mailto:barryleiba(_at_)gmail(_dot_)com] On Behalf
Of
Barry Leiba
Sent: Tuesday, May 24, 2016 3:49 PM
To: Roni Even
Cc: General Area Review Team; draft-leiba-cotton-iana-
5226bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; IETF discussion list
Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
Hi, Roni, and thanks for the review.
I am wondering about the lack of normative language for example in
section
4.11
“When reviewing a document that asks IANA to create a new
registry or change a registration policy to any policy more
stringent than Expert Review or Specification Required, the IESG
should ask for justification to ensure that more relaxed policies
have been considered and that the strict policy is the right one.”
Is the “should” normative here?
Perhaps you're confusing "normative language" with "2119 key words":
text doesn't need 2119 key words for it to be normative, and this
document quite intentionally does not cite RFC 2119.
The example you give is a perfect one to show why we're not trying to
shoehorn key words that were meant to give instructions for
interoperable protocols into a document that's giving advice for
writing and interpreting IANA Considerations. The sentence above
means exactly what it says in
English: it's advising the IESG, but it is ultimately the IESG's decision.
Barry