[Ietf-not43] 3.2.3 & 3.2.5 requirements

[Andrew Newton]

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

MIII9AYJKoZIhvcNAQcCoIII5TCCCOECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BkYwggMGMIICb6ADAgECAgMHMt4wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA0MTAxODU4MjBaFw0wMzA0MTAxODU4MjBa
MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGFu
ZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5Kc4
10hpxiGBE08UE3H/qKMXC/cx3lQeVKk7/dKSUNZkspeOXZiH/oFyl9tQtcIxQ216EvXo53T1
2QBB044fo+CkitDYvt1zZSHLQY9cBDR3s8FqA7HVHOAyC7BMqUPaSBaliaXDOlPbXBxOkuGY
sBdRAzRv51UdW3HoWAhkGBWCzMCVMru7e1ZGrwtrYqaWXJN37spr7QgHdVmXhjOSu7rMmiDC
UW5IneJomR+nHNiFmjqFqMxFpJw/5MmdjPCjS8iVwbSU0QpFepenIc/Fr0pBH/qDlEX1Tawr
sLlRJA+npwO97b2VViAdajF35k+6c7ZMl4C5NAF0fvN6qzEWfQIDAQABozEwLzAfBgNVHREE
GDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAHF4Ljf5CziCiMSNwm++3gO/XyAXz0aPUNoQNtPj+C3CndMZIgKsxIUnYbLM0EYcZFDZ
O2QTpLB53zq2hT1sdPs3YpgXkJY31s+JsT6zOR6zDYYtdqNuE0cb/BzIZIzhRJlcl3M7zHoy
h/0PnY54cc7m6StJtmfbc2n/sCu1YCoyMIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6R
ATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG
A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp
bEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G
A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRx
oKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGH
gzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3
J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBd
avl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYICdjCCAnICAQEw
gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl
czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBzLeMAkGBSsO
AwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIw
ODA4MTQyNDA3WjAjBgkqhkiG9w0BCQQxFgQUY5F0mBniqGguEaRwojRI47gnsKMwUgYJKoZI
hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAhTtamrPl8WnX6eyG
iYVfngpjBfsaktBkJpmjR6AuFEQ0gMiWGPETQgOJ0i4yaRaSUkWFwlCqeVCHBVRUsUc0/Hbt
18LoxS1puIOPCtHaP1guh39jbI0vz0bQfzjBOi+UqK0RmRhv/ZSeFxOt5lzROEdZbJokxzmL
1I5FdEIF19F+SFLt84Lqr0eik2SUseIcLFqCoe4kPG+Lwq2vysHrfGPAW5cIAFr13ejnXh+X
ji/Qmr3tAeY91RlF81q1w2vMe6ebE/5GvKn+oHfM2iZgIg4iltxGUmSMWE+/9g4sigJi/TNw
OWxKNR9lajzpjqrpkrMBXsTAxuQ4Ag2ai0N+eg==
--=_zark-6513-1028817254-0001-2--