Subject: Re: [P2PSIP] Consensus call on security draft

From: Dan York <[email-masked]>
Date: Wed, 7 Oct 2009 10:30:51 -0400

Enrico,

Thank you for alerting us to this survey and, speaking for the  
security draft author team, I'll say that it definitely sounds like  
something we should consider.  Thanks.

Thank you, as well, for your support of adopting the draft as a WG item.

Dan

On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote:

> The P2P Research Group is publishing a survey on security issues in  
> p2p
> overlays for realtime communications that I think this draft should in
> some ways take into consideration, e.g. discussing how the various
> attacks and possible solutions apply to the very specific P2PSIP case.
> The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG
> review and is now headed to the IESG.
>
> Sorry for not pointing this out earlier -- while this was discussed in
> Stockholm I was probably in a jet lag coma on those fantastic Swedish
> chairs ;-)
>
> Anyways, I support its adoption as WG item.
>
> Enrico
>
> David A. Bryan wrote:
>> As Dan mentions below, there was a call in Stockholm to (pending the
>> changes requested) adopt this work as a WG item:
>>
>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt
>>
>> 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).
>>
>> Thanks,
>>
>> David (as chair)
>>
>> On Mon, Sep 28, 2009 at 5:31 PM, Dan York <[email-masked]> wrote:
>>> P2PSIP working group members,
>>>
>>> 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":
>>>
>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt
>>>
>>> Chairs, per the discussion that apparently happened at IETF75, we  
>>> would like
>>> to ask for this to be considered as a working group document.
>>>
>>> Please note... I made a mistake in the submission process and also  
>>> submitted
>>> this as:
>>>
>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt
>>>
>>> They are IDENTICAL except for the name change.
>>>
>>> Thank you for your consideration,
>>> Dan
>>>
>>> --
>>> Dan York, Director of Conversations
>>> Voxeo Corporation   http://www.voxeo.com  [email-masked]
>>> Phone: +1-407-455-5859    Skype: danyork
>>>
>>> Join the Voxeo conversation:
>>> Blogs: http://blogs.voxeo.com
>>> Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
>>> Facebook: http://www.facebook.com/voxeo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 7 Oct 2009 12:16:38 -0400

Seeing as we've had no objections for a week, I'll take that as list
confirmation of the room consensus Brian called in Stockholm, adopting
the security overview as a WG item.

David (as chair)

On Wed, Oct 7, 2009 at 10:30 AM, Dan York <[email-masked]> wrote:
> Enrico,
>
> Thank you for alerting us to this survey and, speaking for the security
> draft author team, I'll say that it definitely sounds like something we
> should consider.  Thanks.
>
>> The P2P Research Group is publishing a survey on security issues in p2p
>>> about adoption to the list, and we'll make a call after there has been
>>>> At IETF 75, we were given the direction to remove the RFC 2119 language
>>>> from
>>>> informational doc.  I have now started this and made a number of other
>>>> Chairs, per the discussion that apparently happened at IETF75, we would
>>>> like

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2009 09:21:44 -0700

David,

I think calling consensus here is slightly premature.

I have not had time to review this document and plan to do so today.

My impression was Cullen intended to do so as well.

-Ekr

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 7 Oct 2009 12:30:40 -0400

Eric,

I don't agree this is premature in any way.

We've allowed over a week on this topic. 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.

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.

David

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 07 Oct 2009 13:39:12 -0700

At Wed, 7 Oct 2009 12:30:40 -0400,
David A. Bryan wrote:
> 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:

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

Because I had already made comments on the previous version during
the meeting.

> Otherwise, we had consensus in the room and allowed a reasonable time

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

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

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 7 Oct 2009 16:56:08 -0400

Well, I'm not even going to justify ludicrous pedantry over 9 minutes
with a response...moving on to potentially substantive issues...

> Because I had already made comments on the previous version during

While your points below are worth considering, this particular point
by itself is procedurally not relevant. You objected in the meeting,
but despite this, consensus was to adopt the document (if the changes
were made -- see below).

You of course are still welcome to make the same objections on list,
but it there is consensus, the fact you objected before the consensus
call in the room and make the same objection now doesn't lack of
consensus make. See
http://tools.ietf.org/html/draft-dusseault-consensus-00 ...

> word "must" and "30" of the word "should". For example:

etc...

What do others think of this concern? Do you feel that the document
has been sufficiently modified that it reflects the intent of the WG
desire to see it moving toward a tutorial? Obviously it is
unreasonable to ask that it be perfect before it is adopted as WG item
-- this isn't a WG last call, and WG items often are adopted while
needing changes, corrections, additional work, etc.. That said, the
question to the group is:

1) Do others agree with EKR that the document has not moved
sufficiently in the direction requested in Stockholm and thus should
NOT be adopted as a WG item or

2) Do people believe the changes request have more or less been made,
and it should be adopted.

David (as chair)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 07 Oct 2009 14:03:57 -0700

At Wed, 7 Oct 2009 16:56:08 -0400,

David,

Of course, you're mischaracterizing my point, but what's actually
ludicrous is you doing a consensus call with no firm deadline and then
attempting to ignore feedback that arrives within a time period
reasonably implied by your vague deadline. If you intend to be hard
about deadlines, then they need to be clearly stated.

> by itself is procedurally not relevant.

What it's relevant to, David, is your argument that "Bruce started a
thread on the previous version way back on July 25th, and you didn't
comment." Comments don't go away just because they aren't repeated
incessantly.

> With those out of the way, the concern below is a potentially valid one:

The problem here, David, is that you don't have consensus to accept
this document in its current state. As I stated, there was consensus
in the room to accept the document pending a particular set of
changes. I claim those changes have not been made. Absent an
affirmative showing on the list or in a meeting that there is
consensus that those changes have in fact been made at this time,
there simply is no showing of consensus to accept this document as-is
and having it published as a WG document is a process error.  Silence
is not consent.

-Ekr

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 7 Oct 2009 17:22:09 -0400

> about deadlines, then they need to be clearly stated.

I'm not mischaracterizing your point at all. Honestly, did you intent
to comment in those 9 minutes? I stated at least a week. There was not
serious discussion (other than one post in favor of adoption, and no
objections) for several days, so it seemed that since the issue was
settled, and the week had passed, it was time to move on.

> and having it published as a WG document is a process error.  Silence

I have again asked the list for input on the concern you raised that
the document doesn't reflect the changes requested. Do they feel this
document has changed sufficiently to meet the requirements for the hum
for adoption Brian called in Stockholm? The authors felt they had made
the changes, and asked the chairs to verify this on list. The only
comment was a positive. You have objected now, so I asked the list
again for their thoughts on adoption.

As I am sure you are well aware, consensus can be changed, or heck,
the group can have consensus to un-adopt a document months later,
decide that an editorial team isn't responsive to the WG and choose a
different document in it's place, etc.

As of now, the question has been posed to the list again. Do they feel
the new document has made sufficient changes to meet the intent of the
WG's comment in Stockholm, and feel the document should be adopted? As
you have objected, we'll declare that no consensus has been reached
yet, and we'll see what the thoughts are on list, but there is no
process error here.

David (as chair)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 07 Oct 2009 15:34:47 -0700

At Wed, 7 Oct 2009 17:22:09 -0400,
David A. Bryan wrote:
> to comment in those 9 minutes?

As I stated, I intended to send comments today, which seems well
within the bounds of "at least a week."

> I stated at least a week. There was not

Let's recap:

- You posted a consensus call with a vague deadline of "at least a week"
- After slightly less than a week, you declared consensus.
- I objected that it was premature.

At this point, you had the option of just saying "oops, I guess we don't
have consensus" and waiting for my review and whatever discussion ensued.

Instead, you opted to get defensive, insist that it wasn't premature,
assert that you had "allowed over a week on this topic, and generally
blow a lot of smoke about how I hadn't commented in time. It was in
that context that I observed that you hadn't even waited a full
week. Is it nitpicky? Sure. But if you're going to announce vague
deadlines and then treat them as hard, that's what you need to expect.

> yet, and we'll see what the thoughts are on list, but there is no

I agree that there is not currently a process error. However, if this 
document is adopted as a WG document based on silence rather than 
affirmative consensus, that would be a process error.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Thu, 08 Oct 2009 19:52:51 +0200

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-masked] [mailto:[email-masked]] 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
> 
> __________ 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

---

From: Song Haibin <[email-masked]>
Date: Fri, 09 Oct 2009 10:28:55 +0800

Hi Eric,

The only comment raised by you during the meeting and in the mailing list is
about the RFC 2119 language. Roni has replied and gave the authors'
explanation in the mailing list. We have not received any further comments
after your planned review.

Thanks!
Haibin

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Eric Rescorla
>Sent: Thursday, October 08, 2009 12:22 AM
>To: David A. Bryan
>Cc: P2PSIP WG
>>>> p2p overlays for realtime communications that I think this draft 
>>>> should in some ways take into consideration, e.g. 
>discussing how the 
>>>> various attacks and possible solutions apply to the very 
>specific P2PSIP case.
>>>> Sorry for not pointing this out earlier -- while this was 
>discussed 
>>>> in Stockholm I was probably in a jet lag coma on those fantastic 
>>>> Swedish chairs ;-)
>>>>
>>>>> As Dan mentions below, there was a call in Stockholm to (pending 
>>>>> the changes requested) adopt this work as a WG item:
>>>>>
>>>>> 
>>>>> 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).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David (as chair)
>>>>>
>>>>>> 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":
>>>>>>
>>>>>> 
>>>>>> would like to ask for this to be considered as a working group 
>>>>>> document.
>>>>>>
>>>>>> submitted this as:
>>>>>> Dan York, Director of Conversations Voxeo Corporation   
>>>>>> http://www.voxeo.com  [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 9 Oct 2009 13:31:03 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, October 08, 2009 6:53 PM
> To: 'Eric Rescorla'; 'David A. Bryan'
> Cc: 'P2PSIP WG'
> My understanding is that since there is no reference to RFC 
> 2119 which says that 
> 
> 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.
> >     As the authors feel they have made the requested 
> changes, I'd like 
> > to
> > Because I had already made comments on the previous version 
> during the 
> > meeting.
> > 
> > 
> > > Otherwise, we had consensus in the room and allowed a reasonable 
> > > time for comments on list.
> > 
> > non-normative, as stated by Roni, Brian, and myself. 
> Moreover, this is 
> > confirmed by Dan's message when this document was posted:
> > 
> > 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.
> >    each other with e.g.  TLS and DTLS.  If transport 
> service security 
> > is
> >    network participants.  The P2PSIP security should allow 
> the users 
> > and
> 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
> __________ Information from ESET NOD32 Antivirus, version of 
> virus signature database 4491 (20091008) __________
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Oct 2009 07:00:29 -0700

On Thu, Oct 8, 2009 at 7:28 PM, Song Haibin <[email-masked]> wrote:
> about the RFC 2119 language.

This is not correct. If you go listen to the meeting, I complained that this
document seemed extremely generic and disconnected to RELOAD.
Seeing as we already *have* an architecture and a proposed protocol
with a whole bunch of its own security analysis and characteristics,
I don't understand what the purpose of this document is. You can see
this in the jabber log:

15:05:44] <ekr> mic: I'm sort of concerned by how generic this is.
[15:05:45] <Ted(with knees)> Show of hands for readers: a few
[15:05:51] <Cullen Jennings> 3 peopel had read it
[15:06:28] <ekr> IT seems almost totally detached from RELOAD as it
currently is.
[15:07:57] <Adam Roach> Oh, wait. I figured it out. You use recvmsg,
and then iterate the cmsghdrs until you find the one with a cmsg_type
of IP_TTL
[15:08:09] <Ted(with knees)> waiting by mic, ekr
[15:08:09] <Adam Roach> So it looks like there's no problem doing the
TTL trick on either end
[15:09:16] <Ted(with knees)> okay heading back
[15:09:20] <ekr> mic: I think Cullen has sort of hit my concern. This
seems like a security analysis of some hypothetical unspecified
protocol that sort of is vaguely connected to P2PSIP. But we're way
beyond that point. We've got a specific architecture and protocol and
so it's odd to have a security analysis that's unconnected to that.

> Roni has replied and gave the authors'

As I noted in my previous message, the whole tone of this document
remains inappropriate.

If you think you're going to do a purely informative document that's a
tutorial on
P2P/P2PSIP  securing in general (which is what the WG hummed for), then
while I personally don't see the value in it, I have no objection. However,
this document is full of normative/requirements-type language, of which
the use of words like must and should (even in lower case) is merely the
most obvious manifestation. If you're writing a tutorial document, then it
shouldn't be telling people what to do, period. My previous comment
identified a number of these passages but what the document needs is a
complete scrub of all such material.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Fri, 09 Oct 2009 22:40:03 +0200

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

> Behalf Of DRAGE, Keith (Keith)
> Sent: Friday, October 09, 2009 1:31 PM
> To: Roni Even; 'Eric Rescorla'; 'David A. Bryan'
> Cc: 'P2PSIP WG'
> 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
> 
> signature database 4494 (20091009) __________
> 
> signature database 4494 (20091009) __________
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4494 (20091009) __________

http://www.eset.com

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 10 Oct 2009 01:51:14 +0200

If I take the first two "must" usages in the document:

"Thus, the architecture must consider this
   issue in the process of both enrollment and modification of P2PSIP
   resource (user) records in a P2PSIP overlay."

"Nevertheless those
   attacks must be addressed by designers of service specific protocols
   such as SIP [RFC3261]."

Are either of these statements even relevant to a document of tutorial, i.e. educational nature, that the working group defined this to be.

So essentially I am saying, irrespective of whether a reference to RFC 2119 carries a normative nature or not, just changing the "MUST" to a "must" does not achieve the purpose you are trying to write this document for.

The document, according to the scope defined by the working group, should be concentrating on the security issues, rather than writing statements about how the security should be addressed.

regards

Keith

> From: Roni Even [mailto:[email-masked]] 
> Sent: Friday, October 09, 2009 9:40 PM
> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan'
> Cc: 'P2PSIP WG'
> Subject: RE: [P2PSIP] Consensus call on security draft
> 
> Hi Keith,
> 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.
> 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
> 
> > They also raise questions on review as to whether they should have 
> > been upper case, at which point people promptly forget all previous 
> > >       "OPTIONAL" in this document are to be interpreted 
> as described 
> > > in
> > >       RFC 2119.
> > >
> > > 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.
> [mailto:[email-masked]] On 
> > > > Behalf Of Eric Rescorla
> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote:
> > > > >
> > > > > Eric,
> > > > >
> > > > 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"
> > > > > were reviewing, you have made no comments on list about the 
> > > > > draft since Stockholm. Bruce started a thread on the previous
> > > version way
> > > > space. However, it was extremely clear that this 
> document was to 
> > > > be non-normative, as stated by Roni, Brian, and myself.
> > > Moreover, this is
> > > > 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
> > > >    secure hop-by-hop transport service for the P2P 
> overlay.  This 
> > > > alone,
> > > >    The user wants available and reliable service that 
> enables him
> > to
> > > > mechanism for securely providing read-level access in a P2P 
> > > > storage network, which is why RELOAD assumes that data
> > > confidentiality will be
> > > > 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.
> > > > acceptable or that it has consensus: the consensus in Stockholm 
> > > > was contingent on changes that have not been made, and the 
> virus signature database 4494 (20091009) __________
>

---

From: Song Haibin <[email-masked]>
Date: Sat, 10 Oct 2009 17:26:30 +0800

Hi,

Just updated the document a bit with removing RFC 2119 requirement languages
(no reference to RFC 2119 in this document). The link for the new version is
as below:

http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-overvi
ew-01.txt

Thanks!
Haibin

>On Behalf Of DRAGE, Keith (Keith)
>Sent: Saturday, October 10, 2009 7:51 AM
>Are either of these statements even relevant to a document of 
>tutorial, i.e. educational nature, that the working group 
>defined this to be.
>
>So essentially I am saying, irrespective of whether a 
>reference to RFC 2119 carries a normative nature or not, just 
>changing the "MUST" to a "must" does not achieve the purpose 
>you are trying to write this document for.
>
>The document, according to the scope defined by the working 
>group, should be concentrating on the security issues, rather 
>than writing statements about how the security should be addressed.
>
>regards
>
>Keith
>
>> 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.
>> 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
>> 
>> > > >    their P2PSIP resource (user) records.  The owner of 
>a P2PSIP 
>> > > > resource
>> > > > overwhelming silence on the mailing list after this 
>revision is 
>> > > > not at
>> > > all the same
>> > > > as consensus.
>> > > >
>> > > > -Ekr

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Thu, 22 Oct 2009 17:44:36 +0800

Hi Haibin,

Well done! I think this draft should be adopted as WG Item now, as
consensus got in IETF#75. Thanks.

Br
Xiao, Lin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Song Haibin
Sent: Saturday, October 10, 2009 5:27 PM
To: 'DRAGE, Keith (Keith)'; 'Roni Even'; 'Eric Rescorla'; 'David A.
Bryan'
Cc: 'P2PSIP WG'
Subject: Re: [P2PSIP] Consensus call on security draft

Hi,

Just updated the document a bit with removing RFC 2119 requirement
languages (no reference to RFC 2119 in this document). The link for the
new version is as below:

http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-ov
ervi
ew-01.txt

Thanks!
Haibin

>Are either of these statements even relevant to a document of tutorial,

>i.e. educational nature, that the working group defined this to be.
>
>So essentially I am saying, irrespective of whether a reference to RFC 
>2119 carries a normative nature or not, just changing the "MUST" to a 
>"must" does not achieve the purpose you are trying to write this 
>document for.
>
>The document, according to the scope defined by the working group, 
>should be concentrating on the security issues, rather than writing 
>statements about how the security should be addressed.
>
>regards
>
>Keith
>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Oct 2009 11:24:43 +0100

I am in favour to adopt this version as WG item.

BR
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Xiao, Lin (NSN - CN/Beijing)
Sent: Thursday, October 22, 2009 11:45 AM
To: ext Song Haibin; DRAGE, Keith (Keith); Roni Even; Eric Rescorla;
David A. Bryan
Cc: P2PSIP WG
Subject: Re: [P2PSIP] Consensus call on security draft

Hi Haibin,

Br
Xiao, Lin 

-----Original Message-----

Hi,

Thanks!
Haibin

---

From: Song Haibin <[email-masked]>
Date: Mon, 26 Oct 2009 18:44:55 +0800

Hi Christian,

Thank you for your comments to this document and for your support for
adoption.

Haibin

>From: Schmidt, Christian 1. (NSN - DE/Munich) 
>[mailto:[email-masked]] 
>Sent: Monday, October 26, 2009 6:25 PM
>To: Xiao, Lin (NSN - CN/Beijing); ext Song Haibin; DRAGE, 
>Keith (Keith); Roni Even; Eric Rescorla; David A. Bryan
>Cc: P2PSIP WG
>On Behalf Of ext Xiao, Lin (NSN - CN/Beijing)
>To: ext Song Haibin; DRAGE, Keith (Keith); Roni Even; Eric 
>Rescorla; David A. Bryan
>Cc: P2PSIP WG
>Well done! I think this draft should be adopted as WG Item 
>now, as consensus got in IETF#75. Thanks.
>
>
>Br
>Xiao, Lin 
>
>On Behalf Of ext Song Haibin
>Just updated the document a bit with removing RFC 2119 
>requirement languages (no reference to RFC 2119 in this 
>document). The link for the new version is as below:
>
>tutorial,
>and if it 
>understand