Hi Eric,
About RFC 2119 language.
My understanding is that since there is no reference to RFC 2119 which says
that
"In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used."
My understanding is that there is no normative text in the document. The
meaning of "must" and "should" when not specified by RFC 2119 does not make
them normative.
Furthermore the document will be an Informational document
Roni Even
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Eric Rescorla
> Sent: Wednesday, October 07, 2009 10:39 PM
> To: David A. Bryan
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] Consensus call on security draft
>
> At Wed, 7 Oct 2009 12:30:40 -0400,
> David A. Bryan wrote:
> >
> > Eric,
> >
> > I don't agree this is premature in any way.
> >
> > We've allowed over a week on this topic.
>
> Well, David, since you insist: your mail asking for a consensus call
> was sent at 12:25 EST on the 30th and stated:
>
> As the authors feel they have made the requested changes, I'd like
> to
> ask folks on list to confirm this consensus. Please send comments
> about adoption to the list, and we'll make a call after there has
> been
> time to review and comment (at least a week).
>
> This mail declaring consensus was posted at 12:16 EST today, so the
> amount of time you have allowed, rather than being "at least a week"
> is actually just under a week, so even by the most generous
> interpretation of the situation, this is slightly premature. Given
> that you did not provide any real deadline, it is quite premature.
>
>
> > You never posted saying you
> > were reviewing, you have made no comments on list about the draft
> > since Stockholm. Bruce started a thread on the previous version way
> > back on July 25th, and you didn't comment.
>
> Because I had already made comments on the previous version during
> the meeting.
>
>
> > Are there others besides yourself (and Cullen)? If so, speak up now.
> > Otherwise, we had consensus in the room and allowed a reasonable time
> > for comments on list.
>
> While I agree, we had consensus in the room, this document does not in
> fact live up to that consensus. I've just listened to the relevant
> section of the WG meeting and it was quite clear that what the WG
> hummed for was as a general tutorial/overview of security in the P2P
> space. However, it was extremely clear that this document was to be
> non-normative, as stated by Roni, Brian, and myself. Moreover, this
> is confirmed by Dan's message when this document was posted:
>
> At IETF 75, we were given the direction to remove the RFC 2119
> language from
> the document and move it from being a normative doc to a purely
> informational doc. I have now started this and made a number of
> other
> changes, including most notably the name change from
> "p2psip-security-requirements" to "p2psip-security-overview":
>
> While the 2119 language was removed, which is a start (and I realize I
> focused on this over Jabber, but limited bandwidth is a cost of not
> being in the room), the document is full of normative text, albeit
> not rendered in upper case. I count 23 separate instances of the
> word "must" and "30" of the word "should". For example:
>
> S 5.1.
> protected against attacks(such as Man-in-the-Middle). In order to
> establish the identity trust association, nodes must authenticate
> each other with e.g. TLS and DTLS. If transport service security
> is
> provided, we can prevent nodes without valid identities to
> participate in the overlay. This layer must provides reliable and
> secure hop-by-hop transport service for the P2P overlay. This
> alone,
> though, is not enough to secure the P2P system.
>
> S 8.1.
> The user wants available and reliable service that enables him to
> interact with other users and resources in a secure way. This means
> that the P2PSIP system must provide:
>
> Worse yet, some of these actually contradict design decisions that
> have already been made in RELOAD:
>
> S 8.2.11.
> The security of P2PSIP systems must guarantee privacy of the P2PSIP
> network participants. The P2PSIP security should allow the users
> and
> P2PSIP network entities to indicate which other users or P2PSIP
> network entities can retrieve, modify, and delete data stored in
> their P2PSIP resource (user) records. The owner of a P2PSIP
> resource
> (user) record should be able to limit the access to his own resource
> (user) records, and this feature should be enforced by the P2P
> network.
>
> This is a particularly egregious case since there is no known
> mechanism for securely providing read-level access in a P2P storage
> network, which is why RELOAD assumes that data confidentiality will be
> solved by encryption rather than access control.
>
> This material is not even remotely tutorial in nature. Quite the
> contrary, it is requirements text, regardless of the fact that it's
> not capitalized. In order for this document to conform to the
> consensus in Stockholm, then, all this language needs to be
> removed. If the authors/WG feel it is important, it might be replaced
> with descriptions of the security consequences of various design
> choices. However, as it stands, no I don't agree that this document
> either is acceptable or that it has consensus: the consensus in
> Stockholm was contingent on changes that have not been made, and the
> overwhelming silence on the mailing list after this revision is not at
> all the same as consensus.
>
> -Ekr
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4488 (20091007) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4488 (20091007) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4491 (20091008) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4491 (20091008) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
