Subject: [Ietf-not43] 3.2.3 & 3.2.5 requirements

From: [email-masked] (Andrew Newton)
Date: Thu, 08 Aug 2002 10:24:07 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark-6513-1028817254-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ted Hardie wrote:
> 
> > 3.2.5 Domain Information Lookup
> >
> >    The service MUST provide access to operational and social data
> >    specific to a domain given the domain's fully qualified name (FQDN).
> >    This information SHOULD include the following:
> >
> >    o  activation status
> >
> >    o  registrant name and contact data
> >
> >    o  hosting nameservers
> >
> >    o  technical, billing or other entity types associate with the
> >       domain and their relevant contact data, if any exist
> >
> >    o  the name of or a reference to the registry delegating the domain
> >
> >    o  the name of or a reference to the registrar for the domain, if
> >       one exists
> 
> I think SHOULD makes sense here, in its guise as "ought to, unless you
> have a very good reason not to".  A good reason not to having hosting
> nameservers, for example, is that activation status is "Deleted", "pending"
> or some similar non-operational state.  Billing info for deleted entries
> might also be inappropriate, even if a service continued to provide
> an entry like "deleted".  As an example, NASA asked a service using
> its name outside of the bound of the space act of 1952 to desist doing
> so; I can see maintaining a listing of that domain as "deleted"
> so that someone debugging knows that it is deliberately gone.

I don't disagree with what you are saying.  However the MUST really
should be in terms of what the protocols (that make up the service)
should support.  Which elements are or are not included will most likely
depend on site policy.

So, it probably should read, "The service MUST be capable of supplying
the following information for this lookup:".  

And perhaps something about what to do if an operator chooses to omit
something so that implementers know what to expect.  Perhaps, "The
service MUST be capable of expressing these information components in a
predictable and standard structure while allowing operator policy
determine which elements are or are not appropriate for any particular
query instance." Ok, did I screw that up?  Maybe I'll try this again
after another cup of coffee.

Thoughts?

-andy
--=_zark-6513-1028817254-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zark-6513-1028817254-0001-2--

---

From: [email-masked] (Ted Hardie)
Date: Thu, 8 Aug 2002 09:14:06 -0700 (PDT)

> should support.  Which elements are or are not included will most likely

I agree that the service MUST be able to provide the pieces listed.
I think we both agree that there are times when some elements won't
make sense.  It may be the correct thing to do isn't to omit
the elements, but to emit them with null values; this strategy
can be used when an authorization threshold isn't met, the state
doesn't usefully carry the resulting data, and so on.

I'm also not entirely sure that "site policy" is the right way to
describe the test for when something should and shouldn't be present.
The way I see it, the eventual service description should say
something like "when authorization is below the trusted level, the
service should do X".  Sites determine when authorization is below
the trusted level, but don't determine X when the condition is met.
If there are choices, those need to be spelled out or bounded (so
"return an error or re-present credential challenge" or
"notify service management" both work, even though how notifying
service management works isn't described).

Does this make sense?
			regards,
					Ted Hardie

---

From: [email-masked] (Andrew Newton)
Date: Thu, 08 Aug 2002 13:31:19 -0400

--=_zark-8153-1028828486-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> doesn't usefully carry the resulting data, and so on.

Well, that is what I meant.  The schema language used needs to be able
to specify that there is a place for the value of a piece of
information, it is just not provided.  Both the LDAP and XML Schema
approaches can do this.

-andy
--=_zark-8153-1028828486-0001-2

--=_zark-8153-1028828486-0001-2--