Re: [Sip] Resend: Draft Shepherd writeup fordraft-ietf-sip-media-security-requirements-07
Cullen Jennings <fluffy@cisco.com> Fri, 19 September 2008 20:40 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EB43A688B; Fri, 19 Sep 2008 13:40:02 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2E33A688B for <sip@core3.amsl.com>; Fri, 19 Sep 2008 13:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh6idNx6u0G2 for <sip@core3.amsl.com>; Fri, 19 Sep 2008 13:39:55 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E3C633A67D8 for <sip@ietf.org>; Fri, 19 Sep 2008 13:39:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,432,1217808000"; d="scan'208";a="80148616"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Sep 2008 20:40:10 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8JKeAOs022741; Fri, 19 Sep 2008 13:40:10 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8JKe7Pb028662; Fri, 19 Sep 2008 20:40:08 GMT
From: Cullen Jennings <fluffy@cisco.com>
To: Spencer Dawkins <spencer@wonderhamster.org>
In-Reply-To: <04f201c91a62$79d1ce80$6701a8c0@china.huawei.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
X-Priority: 3
References: <FA3F0DCC-B557-4BB7-AA3A-535E9B89CE42@softarmor.com> <175DF185-66E9-4D89-B0EA-6E052D54A306@softarmor.com> <04f201c91a62$79d1ce80$6701a8c0@china.huawei.com>
Message-Id: <F344D15D-6957-4CCE-A67E-6D67D566CC02@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 19 Sep 2008 14:40:02 -0600
X-Mailer: Apple Mail (2.929.2)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9606; t=1221856810; x=1222720810; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20[Sip]=20Resend=3A=20Draft=20Shepherd=20 writeup=20fordraft-ietf-sip-media-security-requirements-07 |Sender:=20; bh=ZtztdBD0NF1fARfulwOPi6FGV9kWsg6CW50AzRW2h3M=; b=qDlOq4U8IYcTya+tF4UgFF288ujkrW1HfddPyv+gyZFnghtiJu/CVbuTmV SC7+FUullda2e0XgqESEO8u2YLP5FKpIQCBsGDrz0Ctwt0SIQ4r98NGc1eE1 Pywwi3zDBL;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: SIP IETF <sip@ietf.org>, Keith Drage <drage@alcatel-lucent.com>, Dan Wing <dwing@cisco.com>, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Resend: Draft Shepherd writeup fordraft-ietf-sip-media-security-requirements-07
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
Outbound is already pub requested and write up is done so I think Dean just had a cut and paste slip up here. On Sep 19, 2008, at 8:17 AM, Spencer Dawkins wrote: > Hi, Dean, > > This is actually for outbound/please ignore the subject line, right? > > Spencer > > p.s. :-) > >> Whoops, I just pasted and sent the wrong version of the writeup. >> Here's the correct one. Note that I originally sent this out in >> June, but we'll be submitting the SRTP framework too, so you get >> another chance here. >> -- >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? >> SIP chair Dean Willis is serving as the Document Shepherd for this >> document. He has personally reviewed this document and believes it >> is >> as ready for forwarding to the IESG for publication as it is ever >> going to get. >> (1.b) Has the document had adequate review both from key WG >> members >> and from key non-WG members? Does the Document Shepherd >> have >> any concerns about the depth or breadth of the reviews that >> have been performed? >> The document has been intensively reviewed within the working >> group. It was formally reviewed by John Elwell: >> http://www.ietf.org/mail-archive/web/sip/current/msg22870.html. >> which resulted in several small changes. >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar >> with >> AAA, internationalization or XML? >> The shepherd has no such concerns. >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the >> document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has >> indicated >> that it still wishes to advance the document, detail those >> concerns here. Has an IPR disclosure related to this >> document >> been filed? If so, please include a reference to the >> disclosure and summarize the WG discussion and conclusion on >> this issue. >> The shepherd has no specific concerns with this document. >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand >> and >> agree with it? >> Working group consensus is quite strong for this document. It was >> considered "high profile" during the entire cycle, and has been very >> thoroughly discussed. Numerous design changes were made in the >> process >> in order to accomodate various points of view. >> (1.f) Has anyone threatened an appeal or otherwise indicated >> extreme >> discontent? If so, please summarise the areas of conflict >> in >> separate email messages to the Responsible Area >> Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> The shepherd is unaware of any extreme discontent with this version >> of >> the draft. A previous version that did not require two "outbound >> proxy" entries was disparaged on-list, but the document was revised >> to >> accomodate this issue. >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See >> http://www.ietf.org/ID-Checklist.html and >> http://tools.ietf.org/tools/idnits/). Boilerplate checks >> are >> not enough; this check needs to be thorough. Has the >> document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >> The document appears to satisfy the various checklist nits. >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents >> that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative >> references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >> References are appropriately divided. There is one reference to a >> draft that has been revised, but this does not impact the document. >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggest a >> reasonable name for the new registry? See [RFC2434]. If >> the >> document describes an Expert Review process has Shepherd >> conferred with the Responsible Area Director so that the >> IESG >> can appoint the needed Expert during the IESG Evaluation? >> This document specifies seven IANA actions that appear to be valid >> and >> complete. It defines no new registry or expert review process. >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly >> in >> an automated checker? >> The document shepherd verified the ABNF using Bill Fenner's checker. >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Write-Up? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >> Technical Summary >> This document defines a n extension to the Session Initiation >> Protocol >> (SIP) that provides for persistent and reusable connections between >> SIP User Agents and SIP Proxy Servers. In particular, this allows >> proxy servers to initiate TCP connections or to send asynchronous UDP >> datagrams to User Agents in order to deliver requests. However, in a >> large number of real deployments, many practical considerations, such >> as the existence of firewalls and Network Address Translators (NATs) >> or the use of TLS with server-provided certificates, prevent servers >> from connecting to User Agents in this way. This specification >> defines behaviors for User Agents, registrars and proxy servers that >> allow requests to be delivered on existing connections established by >> the User Agent. It also defines keep alive behaviors needed to keep >> NAT bindings open and specifies the usage of multiple connections >> from >> the User Agent to its Registrar. >> Working Group Summary >> The working group process on this document was exceptionally long. >> The >> first WG version of the draft appeared in the summer of 2005. Working >> group last call initiated in the summer of 2006 and extended until >> the >> summer of 2008, requring several iterations of the draft and the >> assignment of Francois Audet as a "process champion" for the draft >> within the working group. Most delays seem to have been related to >> slow cycle time on the part of the authors, but the process was also >> delayed by a number of changes occurring during the review cycle. >> Particular sticking points included the keepalive mechanism and a >> requirement for binding to multiple outbound proxies if so >> configured. The latter was eventually resolved by a widely-accepted >> compromise, but the keepalive topic is still being debated. Although >> there is a strong consensus for the keepalive technique specified in >> this document, there is some reason to believe that there may be a >> need for the keeplaive mechanism independently of the outbound >> relationship. There is currently a draft proposing such a mechanism. >> This suggests that it might have been more effective to document the >> outbound binding and keepalive mechanisms independently. >> Document Quality >> There are numerous implementations of the protocol, and it has been >> tested at SIPit events since 2005. >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Draft Shepherd writeup for draft-ietf-sip-m… Dean Willis
- [Sip] Resend: Draft Shepherd writeup for draft-ie… Dean Willis
- Re: [Sip] Resend: Draft Shepherd writeup fordraft… Spencer Dawkins
- Re: [Sip] Resend: Draft Shepherd writeup fordraft… Cullen Jennings
- Re: [Sip] Resend: Draft Shepherd writeup fordraft… Dean Willis