[Ietf-not43] -02 c's and q's...
Ross Wm. Rader
ross@tucows.com
Wed, 6 Nov 2002 13:24:06 -0500
> I don't think the two are at odds. The intent of this requirement is to
> allow operators to participate in an authentication distribution system
> and to make sure they aren't limited to only one or mandated to one. So,
> what about removing the "centralised authority" and replacing it with a
> "federated, distributed system" or something like that? The intent is
> for the optional participation in one or many coordinated systems. And
> perhaps this requirement should include a note specifying it must be
> within the bounds of 3.1.7.
I understand now. What about something like this;
"The service MUST NOT require any Internet registries to participate in
specific authentication systems. The service SHOULD allow the participation
by an Internet registry in federated, distributed authentication system of
their choosing." followed by the note you suggest above?
> Thanks for pointing this out. I never thought the intention was to
> specify only two levels. The intention was to specify multiple levels
> to match the policy needs of the operator. This probably needs reworking.
Gotcha - the intent was not clear from my reading - which would tend to
support your reworking theory ;)
> There was a concern from the particpants in Yokahama that abusive users
> would take advantage of a service that allows them to know in advance if
> they are allowed to issue a query. In other words, they don't want the
> service to advertise its policy because it leads to abuse.
This makes a strong case to allow a toggle for the behaviour
(advertise/no-advertise) and let the policy-wonks sort out the details
during implementation.
> It has been mentioned several times that SRV records should be used to
> find the authoritative server for a particular domain, as opposed to
> starting from a defined well-known or mandated root in another protocol.
> This requirement is worded so that SRV records are not ruled the only
> way to do it, but that this still be done with DNS as the authority
pointer.
>
> I've asked many times in the past for help on rewording this requirement
> to be more readable. So if you have any ideas, I'd like to hear them.
Ahh...okay. Makes sense. I thought you might be talking about the MagicDNS
that we talk about in ICANN (it can do anything ;) Let me chew on it for a
bit and I'll let you know if I can come up with anything.
-rwr
"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright
Got Blog? http://www.byte.org/blog
----- Original Message -----
From: "Andrew Newton" <anewton@verisignlabs.com>
To: "Ross Wm. Rader" <ross@tucows.com>
Cc: <ietf-not43@lists.verisignlabs.com>
Sent: Wednesday, November 06, 2002 12:13 PM
Subject: Re: [Ietf-not43] -02 c's and q's...
> Ross,
>
> Thanks for the comments... my followup is in-line.
>
> Ross Wm. Rader wrote:
> > 3.1.9 - "The service MUST NOT require any Internet registries to
participate
> > in any particular distributed authentication system." seems to be at
odds
> > with 3.1.7 (The service MUST be decentralized in design and principle
and
> > MUST NOT require the aggregation of data to a central repository, server
of
> > entity.) Either the spec is decentralized or its not. I'd much prefer
that
> > 3.1.9 is amended to remove this particular statement.
>
> I don't think the two are at odds. The intent of this requirement is to
> allow operators to participate in an authentication distribution system
> and to make sure they aren't limited to only one or mandated to one. So,
> what about removing the "centralised authority" and replacing it with a
> "federated, distributed system" or something like that? The intent is
> for the optional participation in one or many coordinated systems. And
> perhaps this requirement should include a note specifying it must be
> within the bounds of 3.1.7.
>
> > 3.1.4 - Do we think that two levels of privilege is sufficient. Two
further
> > options here - we could open this up to many levels of privilege that
might
> > be determined by the implementation - or - we could open this up to many
> > levels of privilege that would be determined by the spec.
>
> Thanks for pointing this out. I never thought the intention was to
> specify only two levels. The intention was to specify multiple levels
> to match the policy needs of the operator. This probably needs reworking.
>
> > 3.1.8 - "The service SHOULD NOT provide a mechanism allowing a client to
> > determine if a query will be denied before the query is submitted" - not
> > sure that I get this one. Is there some perceived danger in clearly
marking
> > the door off-limits for unauthorized personnel? Here's a use-case that
> > points out one of the negative implications of not marking the door.
> > Suppose at some point some entity that controls particular information
> > decides that they want to charge for access to that information. Failing
to
> > provide a mechanism for pre-identifying the result/non-result due to
> > privileges will leave the customer without the means to determine if a
> > particular query will yield any useful information to them and may end
up
> > having to paying for no service provided.
>
> There was a concern from the particpants in Yokahama that abusive users
> would take advantage of a service that allows them to know in advance if
> they are allowed to issue a query. In other words, they don't want the
> service to advertise its policy because it leads to abuse.
>
> > 3.2.9 Lastly, can someone explain the DNS Label Referencing requirements
a
> > little bit further. I'm not sure I get how this might/should/could/will
> > work.
>
> It has been mentioned several times that SRV records should be used to
> find the authoritative server for a particular domain, as opposed to
> starting from a defined well-known or mandated root in another protocol.
> This requirement is worded so that SRV records are not ruled the only
> way to do it, but that this still be done with DNS as the authority
pointer.
>
> I've asked many times in the past for help on rewording this requirement
> to be more readable. So if you have any ideas, I'd like to hear them.
>
> > Be gentle - I've spent far too much time with policy documents lately.
;)
>
> Very constructive stuff. Thanks.
>
> -andy
>
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43@lists.verisignlabs.com
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43