Subject: Re: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard

From: [email-masked]
Date: Thu, 12 Feb 2009 08:07:54 -0800 (PST)

Apologies for the lateness of this comment. I only recently found the time to
review this draft.

Althogh I share Chris Newman's concerns about possible uses of this draft and
support the addition of the paragraph he recommends in his DISCUSS vote,  I
also believe the mechanism defined by this draft will provide very useful
functionality in a variety of circumstances and standardization is therefore
entirely appropriate.

My concerns with this draft revolve around the defined set of message types and
the mc field that's part of the vbr-info header field. Possible message type
values are "all", "list", or "transaction". The draft also states that the mc
value is self-asserted by the sender and is intended to be used for auditing
purposes.

My first issue with this is that I don't quite get how message type information
is supposed to be used during certification validity checking. If successful
the DNS lookup produces a list of message types the certifier is willing to
vouch for. But how is message supposed to be checked to see if it is of an
allowed type? The obvious thing to do is to see if the mc field value in the
message is on the list, and the example at the end of section 5 implies that
you're supposed to do such a check. It isn't stated explicitly as a
requirement, however.

If this check is supposed to be done, you're using the mc field as a label, not
simply for auditing purposes as the draft states. And if such a check isn't
performed, I'm not sure I see much point in having message type information as
part of this scheme.

My second issue with message types is the lack of any discussion about 
additional possible message type values. Is this initial set of three value are
that are  allowed now and forever? If so this seems a little shortsighted. If
not there needs to be more discussion of the extensibility model.

My third issue is while I see how the "all" value makes total sense in a DNS
entry, I don't see how it makes sense as an mc value. This also brings up the
issue of how you'd compare mc values to the DNS entries. I would think "all"
would act as a sort of wildcard and match any other value.

Finally, I note that we have already defined something similar to the message
type construct: RFC 3458's message-context. While the list of defined values of
the two typing mechanisms are quite distinct at present, as are the intended
purposes of the field (message-context is intended as an aid to message
processing) I could easily see an argument for a mc value of "fax" or "voice"
having validiity, and given how message-context is used in practice it would
make quite a bit of sense to define a list-message message context value that
would closely parallel the "list" mc value.

Again, given the differences in intended use of these fields there is not
necessarily any conflict between them. That said, it is not exactly unheard of
for "scope creep" to occur. If vbr-info becomes popular I can easily see
email-based applications using the mc value in exactly the way message-context
is currently used, irrespective of what the specifications say.  Such a usage
overlap could prove somewhat problematic given message-context's present use
for things like divvying up mailbox quotas between, say, voice mail and regular
email.

Mind you, I'm not going to go so far as to say the VBR mechanism should drop
the mc field and use message-context instead, but I think the potential
overlaps between these two typing mechanisms needs to at least be looked at.

				Ned