Subject: Re: [weirds] FW: I-D Action: draft-kucherawy-weirds-requirements-02.txt

From: Peter Koch <[email-masked]>
Date: Thu, 2 Feb 2012 20:45:18 +0100

On Tue, Jan 31, 2012 at 11:04:57PM -0800, Murray S. Kucherawy wrote:
> This is mostly just to refresh the expired timer, but I cleaned out some stuff that isn't needed and took some baby steps toward making it focus on number registries without leaving out name registries entirely.
> 
> Happy to take more feedback, or we can just leave it as-is as a starting point for when the WG actually forms.

some of these requirements are expressed as - almost operational - requirements
to the client, the server or both where I believe it would be more appropriate
to address the protocol itself.
Example:

   2.  A client SHOULD support caching of replies.  It MAY apply its own
       default and MAY use a time-to-live provided as part of the reply.

really means that the protocol should support caching in the first place.

Also,

   3.  A server SHOULD be able to provide class-of-service facilities
       for different types of users.  At least the following cases need
       to be considered:

       anonymous:  Users with no prior arrangement for access to the
          data; typically all available data will be provided in
	[...]

is different from requiring the protocol to support the identification and
classification of different (types of) users.  Let's keep the boundary between
policy and protocol clean, please.

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Feb 2012 11:58:05 -0800

> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Thursday, February 02, 2012 11:45 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [weirds] FW: I-D Action: draft-kucherawy-weirds-requirements-02.txt
> 
> some of these requirements are expressed as - almost operational -
> requirements to the client, the server or both where I believe it would
> be more appropriate to address the protocol itself. [...]
> 
> is different from requiring the protocol to support the identification
> and classification of different (types of) users.  Let's keep the
> boundary between policy and protocol clean, please.

Would you suggest adding a third section that talks about protocol requirements, and just move those into that?

-MSK

---

From: Peter Koch <[email-masked]>
Date: Fri, 3 Feb 2012 09:59:44 +0100

> Would you suggest adding a third section that talks about protocol requirements, and just move those into that?

I'd think that the draft should focus on the protocol and leave specific
targets (client or server) for a subsequent protocol document to phrase.
So, the 'client should cache' would translate into 'the protocol SHOULD
support client side caching of responses' and 'A server SHOULD be able to provide
class-of-service ...' would probably translate into 'the protocol SHOULD support
optional authentication and authorization'.  I18N is a requirement for
the protocol, too, as is a referral mechanism.
So, I'm not suggesting to drop any of these (maybe later, though ...)
but to rephrase.  That way much of the policy spin ("A server MUST provide a
minimum set of data about a given query.") would be reduced to what is
in scope for the IETF: make the data representation interoperable rather than
requiring what data has to be present.

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Feb 2012 10:39:47 -0800

> Sent: Friday, February 03, 2012 1:00 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> I'd think that the draft should focus on the protocol and leave
> specific targets (client or server) for a subsequent protocol document
> to phrase.
> support client side caching of responses' and 'A server SHOULD be able
> to provide class-of-service ...' would probably translate into 'the
> protocol SHOULD support optional authentication and authorization'.
> I18N is a requirement for the protocol, too, as is a referral
> mechanism.
> but to rephrase.  That way much of the policy spin ("A server MUST
> provide a minimum set of data about a given query.") would be reduced
> to what is in scope for the IETF: make the data representation
> interoperable rather than requiring what data has to be present.

Ah, I see what you're after now.  And that all seems fine to me.  I'll queue it up for -03 (or -00 as a WG item, depending on timing).

Thanks,
-MSK