Hi Keith, My question was about what does it mean to have words like "must", "should" when you do not reference RFC 2119. My take is that RFC 2119 defines the normative terminology and if it does not say that the document refers to RFC 2119 terminology than it does not. In this case there is no normative terms in a document. I was also confused about the text in RFC 2119 and do not understand how is the force of the words changes based on the requirement level of the document . This is why I claim that by my understanding of RFC 2119, if you do not reference it than there is no normative text in the document does not matter if it lower or upper case. Also having the document as informational weakens any strength of text in a document Regards Roni Even
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of DRAGE, Keith (Keith) > Sent: Friday, October 09, 2009 1:31 PM > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Consensus call on security draft > > My view is that using RFC 2119 words in a document even in lower case > is bad practice. It takes a slip of the editing pen for them later to > become uppercase. > > They also raise questions on review as to whether they should have been > upper case, at which point people promptly forget all previous > decisions on the matter and make them upper case. > > Moreover, evaluating such current usage will undoubtedly make the > document become clearer. Just changing upper case to lower case will > not result in a clear informational document. > > So I would support Eric in asking for a version of this document that > does not include any of the RFC 2119 language words, unless of course > there is agreement that normative material should later be included. > (There are some exceptions to this, e.g. quotation from another RFC). > It appears to me that nobody is diputing that the current consensus is > that the document should be tutorial. > > regards > > Keith > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Roni Even > > Sent: Thursday, October 08, 2009 6:53 PM > > To: 'Eric Rescorla'; 'David A. Bryan' > > Cc: 'P2PSIP WG' > > Subject: Re: [P2PSIP] Consensus call on security draft > > > > 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 > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4494 (20091009) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4494 (20091009) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4494 (20091009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
