Subject: [secdir] secdir review of draft-melnikov-imap-keywords-06

From: Samuel Weiler <[email-masked]>
Date: Mon, 9 Nov 2009 15:44:39 -0500 (EST)

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

>From a security perspective, I have no issues with this document. 
It creates a new registry and defines two sets of assignment metrics, 
one for "common use" keywords, and one for vendor-specific keywords.

It also registers four keywords.  (I'm wondering if it shouldn't be 
registering more.)

I'm finding the IANA assignment metrics to be a little more 
ambiguous that I'd like.

Starting with the vendor-specific text:

    Registration of vendor specific IMAP keywords is done on First Come
    First Serve [RFC5226] basis and doesn't require the Expert Review.
    However such review is still encouraged.  Should the review be
    requested, ...

Who requests the review?  The registrant or IANA?  Does IANA need to 
encourage the review?  Perhaps it would be better to have all requests 
(including vendor-specific) be sent to the mailing list, with IANA 
assignment of the vendor-specific ones being automatic following a 
(short) delay for comment and optional revision.

And for the common-use:

    Registration of an IMAP keyword intended for common use (whether or
    not they use the "$" prefix) requires Expert Review [RFC5226].  IESG
    appoints one or more Expert Reviewer, one of which is designated as
    the primary Expert Reviewer.  IMAP keywords intended for common use
    SHOULD be standardized in IETF Consensus [RFC5226] documents. ...
    In cases when an IMAP
    Keyword being registered is already deployed, Expert Reviewers
    should favour registering it over requiring perfect documentation.

Would it be better to say: "requires either IETF Consensus or Expert 
Review"?  (For example: do the registrations made in this doc have to 
go through Expert Review?  Isn't it enough to have them in a consensus 
doc?")  And how do you expect the expert to encourage/enforce the 
SHOULD, given the "favour registering it over requiring perfect 
documentation" guideline?  Again, the current text isn't as clear as 
I'd like.

-- Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Nov 2009 08:17:05 +0000

Hi Samuel,
Thank you for the review.

Samuel Weiler wrote:

> From a security perspective, I have no issues with this document. It 
> creates a new registry and defines two sets of assignment metrics, one 
> for "common use" keywords, and one for vendor-specific keywords.
>

Further registrations will be done by the designated expert. I am 
concerned that if I put all of them in the document, then the document 
will never finish.

> I'm finding the IANA assignment metrics to be a little more ambiguous 
> that I'd like.
>
> Who requests the review?

> The registrant or IANA?

Good question. I was thinking about the registrant. But IANA requesting 
review would be a good idea as well.

> Does IANA need to encourage the review?  Perhaps it would be better to 
> have all requests (including vendor-specific) be sent to the mailing 
> list, with IANA assignment of the vendor-specific ones being automatic 
> following a (short) delay for comment and optional revision.

Ok, I've implemented this procedure in my copy.

> Review"?

Not everybody is subscribed to ietf or ietf-announce mailing lists, so I 
would like for all common use registrations to go through the expert.

> (For example: do the registrations made in this doc have to go through 
> Expert Review?

No, because they are a part of the document that creates the registry ;-).

> Isn't it enough to have them in a consensus doc?")  And how do you 
> expect the expert to encourage/enforce the SHOULD, given the "favour 
> registering it over requiring perfect documentation" guideline?  
> Again, the current text isn't as clear as I'd like.

This is intentional. This is a judgment call by the expert.

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 28 Nov 2009 16:13:51 -0500 (EST)

On Wed, 18 Nov 2009, Alexey Melnikov wrote:

> concerned that if I put all of them in the document, then the 
> document will never finish.

Sympathies.

> would like for all common use registrations to go through the expert.

I don't like the logic (while not everybody is subscribed to the 
lists, your expert surely could be, and it's easy from an AD to punt 
the doc to the expert).

That said, since you want everything to go through the expert, to 
avoid confusion, I suggest removing the citation to the inapplicable 
5226 metric: "IETF Consensus [RFC5226]".

>> Isn't it enough to have them in a consensus doc?")  And how do you expect 
>> the expert to encourage/enforce the SHOULD, given the "favour registering 
>> it over requiring perfect documentation" guideline?  Again, the current 
>> text isn't as clear as I'd like.
>

This sounds inconsistent.  I'm hearing "it's within the scope of the 
expert's judgement to require an IETF Consensus doc" and "In cases 
when an IMAP Keyword being registered is already deployed, Expert 
Reviewers should favour registering it over requiring perfect 
documentation."  If I were an implementer who got told "you need a 
consensus doc", I'd be more than a little tempted to go ahead and 
deploy, then reapply for the registration.

-- Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Nov 2009 21:29:46 +0000

Samuel Weiler wrote:

>> Not everybody is subscribed to ietf or ietf-announce mailing lists, 
>> so I would like for all common use registrations to go through the 
>> expert.
>
> lists, your expert surely could be,

People have complained about traffic on the ietf mailing list during 
plenaries.

> and it's easy from an AD to punt the doc to the expert).

That part is easy, yes.

> 5226 metric: "IETF Consensus [RFC5226]".

Ok, I will try to clarify.

>>> (For example: do the registrations made in this doc have to go 
>>> through Expert Review?
>>
> This sounds inconsistent.

Yes, but it is a fact of life. It is not worse than the current 
situation where people just deploy stuff without bring it to any 
standard mailing list.

> I'm hearing "it's within the scope of the expert's judgement to 
> require an IETF Consensus doc" and "In cases when an IMAP Keyword 
> being registered is already deployed, Expert Reviewers should favour 
> registering it over requiring perfect documentation."  If I were an 
> implementer who got told "you need a consensus doc", I'd be more than 
> a little tempted to go ahead and deploy, then reapply for the 
> registration.

Well, if one works for Microsoft, Google, Mozilla, etc. (not trying to 
pick on anybody), then one does it every time.
Hopefully Expert Review is low enough bar to tempt people (if tempt is 
the right word here at all) to register.

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 Nov 2009 17:13:26 -0500

--On Saturday, November 28, 2009 9:29 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>...
>> I'm hearing "it's within the scope of the expert's judgement
>> to  require an IETF Consensus doc" and "In cases when an IMAP
>> Keyword  being registered is already deployed, Expert
>> Reviewers should favour  registering it over requiring
>> perfect documentation."  If I were an  implementer who got
>> told "you need a consensus doc", I'd be more than  a little
>> tempted to go ahead and deploy, then reapply for the
>> registration.
>
> Well, if one works for Microsoft, Google, Mozilla, etc. (not
> trying to pick on anybody), then one does it every time.
> Hopefully Expert Review is low enough bar to tempt people (if
> tempt is the right word here at all) to register.

Sam,

For whatever it is worth, the above exchange goes to the very 
root of the question of what we think our registration 
procedures and registries are for, at least when there isn't a 
scarcity of possible identifiers.  One theory is that they 
should be designed to prevent garbage, or warn people against 
garbage by the fact that something isn't registered.  I think 
we've seen ample evidence that theory doesn't work, with your 
comments and Alexey's above both constituting examples.  The 
other is that the main purpose of registration is to provide 
sufficient information and documentation to promote 
interoperability by virtue of encouraging people to avoid using 
the same identifier for different purposes.

I'm more optimistic about the second than the first, but it 
calls for a fairly low bar on registrations.

Neither model has much to do with security: registration, no 
matter how high or low the threshold, won't prevent an attack if 
someone is inclined to misuse or reuse an identifier in a 
malicious way.  Nor will non-registration help avoid someone 
finding out what an identifier looks like an attacking whatever 
it represents if one were inclined to do that... only the most 
dedicated believer in security through obscurity could believe 
that non-registration is helpful in that regard and it would be 
a stretch even then.

   john

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Nov 2009 15:15:09 +0200

> lists, your expert surely could be, and it's easy from an AD to punt 

Acting as an IANA expert for IKEv2 registries, I have noticed that
expert do not get any option to say anything for documents which go
through IESG. The IANA registry is just updated without any discussion
with expert in those cases. So I do not think whether it affects
anything if you say "requires Expert Review" compared to the "requires
Expert Review or IETF Consensus", or at least you might want to add
explicit text to make it sure that the review policy mandates that all
assignments go through the Expert..
-- 
[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 30 Nov 2009 18:42:30 +0100

Samuel Weiler answers Alexey:
>>> expect the expert to encourage/enforce the SHOULD, given the 
>>> "favour registering it over requiring perfect documentation" 
>>> guideline?  Again, the current text isn't as clear as I'd like.
>>

That's now how it happens. The consensus issues mostly have been about 
naming (different names for the same thing), and IMO were caused by 
lack of knowledge/communication. Merely talking two the expert would 
likely fix most.

Also, I'd like to mention that Lisa asked two people whether they could 
serve; both of her nominees are people who would be likely to give 
helpful answers, not send implementers away with one-sentence answer 
such as "go write a consensus doc".

Arnt