I would like to return to this point since I think that Doug's comments and my own can be accomodated through a fairly simple change to the requirements language.
The current language is: The Protocol MUST NOT invent a different means of allowing affiliated parties to sign on a domain's behalf. <extended rationale> This strikes me as being a major overstatement of the consensus on the list which was that an additional delegation mechanism is not required. In the standards world there is a huge difference between 'not required' and 'MUST NOT'. Furthermore this is the only point where an extended rationale is presented. I would prefer to omit the point entirely. There are many requirements that are reasonably met in base that should not be repeated in policy and the requirements document should not be required to state each one. Instead the correct approach would be to have a section on architectural requirements that states something like 'The policy mechanism SHOULD NOT duplicate in whole or in part any functionality already supported in base. Although the proposal I have presented does not support policy delegation at the current time I don't want to have to spend time trying to work out if there is a way that this could be achieved and then introduce artificial constraints in order to prohibit this. Furthermore I don't agree with the premise that key delegation is the same thing as policy delegation and that provision of a mechanism for one makes the other unnecessary. If I am configuring my mail to go through an ISP mail server the semantics I want from the delegation mechanism are 'let the ISP decide everything to do with this'. So in that case the delegation would be policy and policy alone. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Hallam-Baker, Phillip > Sent: Monday, October 23, 2006 2:17 PM > To: [email protected] > Subject: [ietf-dkim] More Comments on > draft-ietf-dkim-ssp-requirements-02.txt > > Section 6.3 req 7 > > I don't see what this is driving at at all and at most it > should be a SHOULD. > > I don't know if my proposal allows for a new mechanism for > delegation or not. Making it impossible to use it in this > fashion strikes me as special pleading for the existing proposal. > > In particular I don't see a single positive reason given for > the requirement. Instead what I see is an argument that 'you > can do delegation this way'. That may be so but the mechanism > proposed is not simple. > > > What I am proposing is that we jettison the existing proposal > and replace it with a simple unordered sequence of tag value > pairs, each of which describes a constraint that is met by > all mail sent. > > The tags being: > NULL > NOMAIL > DKIM [=selectorprefix] > > The NULL tag is equivalent to an empty list but may help > readability (this policy intentionally left blank). The > NOMAIL tag has the obvious meaning. > > If the DKIM tag has no parameter it means 'there is always a > DKIM record with a selector corresponding to the email address'. > > If a parameter is specified then the selector on the > signature must match the selector. > > > I see no reason to artificially constrain the selector, > writing the constraint rules is itself a difficult issue. > > Nor do I see the logic here. If I am delegating my mail > service to Fred then I want to write a single DNS record that > says 'Fred is responsible for everything' and have done with > it for all time. The requirements draft is misworded, if we > follow that approach we require the party performing the > delegation to maintain key records. > > > This is a bogus requirement, it should be eliminated. What it > seems to be intended to say is not necessary to say. All > things being equal people will choose the simpler solution. > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
