[Ietf-not43] -02 c's and q's...

[Andrew Newton]

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