Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 comments

From: Thomson, Martin ^lt;>
Date: Thu Jul 10 2008 - 00:48:22 EDT

I have this problem: I assume that people are able to extract meaning from what I write, rather than picking up on superficial details. I stand by the statement, based on its intent. I was making a comment, not a suggestion for text. And it was for the intro section, if you hadn't noticed.

If you want to discuss the philosophy of requirements, there are rats in that hole. I don't view a requirements document of this nature as being any different to a protocol document that specifies requirements for a protocol implementation. SHOULD has a place in each as a way of allowing flexibility in implementation.

If you want a suggestion for text, here:

  C2. Location URI expiration: A location URI SHOULD expire. Location URIs that use authorization by possession MUST expire.

  Motivation: A location URI that is somehow acquired by an attacker could be used indefinitely unless the reference expires. Cancellation only works if the Rule Maker or Target is aware that the URI has been stolen. Expiration limits the loss of private data caused by exposure of the location URI. Where authorization policies are employed, time limits in the authorization policy can be used to limit the impact of unintentional exposure; however, where possession implies authorization, an attacker could gain access to location information for an indefinite period.

I think that this includes sufficient justification for the SHOULD. In this case, as in other, MUST strength is unnecessary. Too strict requirements would be an unnecessary impediment to protocol implementation. In this case, I can envisage a protocol where the authorization policy is used and stable references are important.

Alternative text for C7:

  C7: Location URI expiration indication: A location configuration protocol MUST provide a means to indicate when a location URI expires.

  Motivation: As for existing C7.


> -----Original Message-----
> From: James M. Polk []
> Sent: Thursday, 10 July 2008 1:07 PM
> To: Thomson, Martin; Roger Marshall
> Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 comments
> At 08:12 PM 7/9/2008, Thomson, Martin wrote:
> > {S} Next paragraph: Justification for expiry needs to include
> > security. This is the primary use, particularly where references
> > use the "possession" model. Expiry limits the time that accidental
> > leaking of a URI causes. (from a requirements perspective I tend
> > towards a MUST use, but would be happy with SHOULD use and MUST
> > implement - c.f. HELD design). I have another comment on Section 4
> > on this topic.
> I have an issue with this statement about the draft.
> SHOULD or MUST "use" is not up to a requirements document, I don't
> believe. Protocol documents talk about the hazards of not enabling a
> function or capability, Requirements documents need to MUST virtually
> everything, otherwise the document is ambiguous. Requirements
> documents are specifically for protocol designers, not for
> education. The comment about "SHOULD use" is pointless unless it
> MUST be implemented, which is towards the coming standards track RFC
> authors.
> I think that is confusing the point of a requirements document (i.e.
> it's for protocol authors). Protocol documents have MUSTs and
> SHOULDs, which are towards implementors. SHOULD need to always have
> a legitimate reason to ignore why a SHOULD is not created within a
> protocol and implemented by coders.
> Therefore, I believe the "SHOULD use" point trying to be made here
> needs to be moved into the Intro section, to give another use-case or
> to give further justification for this protocol (to-be) to be designed.
> my 1.75 cents

This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
Geopriv mailing list
Received on Wed, 9 Jul 2008 23:48:22 -0500

This archive was generated by hypermail 2.1.8 : Thu Jul 10 2008 - 00:48:36 EDT