From ietfdbh@comcast.net Fri May 1 07:05:40 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF08228C1CE for ; Fri, 1 May 2009 07:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 aAq0ZFtpl4uy for ; Fri, 1 May 2009 07:05:38 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 2590528C1A4 for ; Fri, 1 May 2009 07:05:37 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id mBaa1b0030vyq2s59E72ft; Fri, 01 May 2009 14:07:02 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id mE711b00u0UQ6dC3RE72N7; Fri, 01 May 2009 14:07:02 +0000 From: "David Harrington" To: , , References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> Date: Fri, 1 May 2009 10:07:00 -0400 Message-ID: <046701c9ca66$192b68c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAIQ1s8A== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:05:40 -0000 Hi, inline. > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, April 30, 2009 7:02 PM > To: ietfdbh@comcast.net; lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org; > iab@ietf.org; Black_David@emc.com > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > Maintenance (storm) > > Let me start by acknowledging that David Harrington is right > about the absence of operations and management in the charter. > At a minimum, the new iSCSI features strongly suggest an > updated version of the iSCSI MIB (RFC 4544), and I need to > revise the draft charter to include that. If David Harrington > is willing to serve as a technical advisor to facilitate this > update, that would be helpful. Part of my concern is whether SNMP MIBs are the correct answer for storage management. I do not know the answer to the question. Much of the charter discusses bringing the IETF storage standards into compliance with implementation/deployment reality. I think the WG should also consider how to bring the storage MIBs into compliance with implementation/deployment reality. At a minimum, if new features are added to the IETF storage stanards, then the MIBs should also be updated. (I'll check with my bosses to see if they will support my acting as MIB/OPS technical advisor.) But if the storage MIBs are not being used, and other management standards are used for managing storage, then maybe the IETF needs to acknowldge that reality and have our standards accommodate that. > > OTOH, I disagree with the suggestion that the WG "consider > and document" ... "what changes might need to be made to > utilize the existing non-IETF standards to manage the updated > IETF storage standards". IMHO, it is usually better to > communicate the functional changes that the IETF is making > in its protocols to other standards organizations that > are responsible for related (e.g., management) standards. > That enables those organizations to make any changes that > they deem appropriate based on their expertise - in contrast, > issuing explicit instructions to another standards organization > has the potential to go over badly (IMHO). The draft charter > already contains references to working relationships with T10 > and T11 - it looks like it needs corresponding text for SNIA > around the iSCSI HBA API and SMI-S support for iSCSI. I think you misunderstood my intentions. If non-IETF standards for management (SNIA SMI-S and T10/T11 HBA) are widely used in the real world, and IETF management standards are not widely used to manage iSCSI, FCIP, etc., then we should consider how **our** standards - iSCSI, FCIP, storage MIBs, etc., should be modified to work better with those widely-deployed non-IETF standards for storage management. Or whether a combination of IETF management standards (syslog, netconf, and SNMP) would be more suitable than the SNMP-only approach. If SCSI is usually managed using HBA and not SNMP, then we should consider whether **i**SCSI needs to be changed to allow consistent (both i* and non-i*) SCSI management. Maybe we need changes to iSCSI to make it compatible with SNMP and HBA and SMI-S. > > Not announcing the BoF on the IETF list was my oversight; > that clearly should have been done prior to San Francisco. > I'll work with Lars on ensuring that there is sufficiently > broad IETF exposure and review of the proposed storm charter. Thanks. > > For the security concerns, please see RFC 3723 (Securing > Block Storage Protocols over IP). I expect that RFC to > remain applicable to all of the revised protocols, with the > overall approach being that security issues in technology that > is standardized by another standards body are the responsibility > of that standards body; would a statement to that effect (RFC > 3723 expected to remain applicable, security issues in standards > from other organizations remain the responsibility of those > organizations) in the charter be helpful? Having such a statement would have made it clearer to people like me who are not in the other organizations. > > That said, I am surprised by what appears to be an inference > that lack of mention of security in the charter implies that > security may not be addressed at all. All RFCs have to address > security considerations, making security something that every > IETF WG has to address, independent of whether security is > explicitly mentioned in the WG charter. If every WG charter > now has to have a "Security Considerations" section, there are > number of WG charters on the IETF web site that need updates > ... surely the IESG has better things to do ;-). I did not overlook that you would need to deal with Security Considerations. I did overlook RFC3723. There are lots of documents related to iSCSI and iFC and FCIP and iSNS and ... I simply haven't had time to study all of them. The problem I have is that I could not look at the documents from INCITS to determine the status of security for SCSI/iSCSI and FC/FCIP, etc. I suspect the INCITS documents do not directly discuss iSCSI security. My impression is T10/T11 focus on non-Internet connectivity, where security concerns/threats might be different than for Internet connectivity. INCITS did make public their intention to update SAM-4 to address security. Apparently they think there is something that needs addressing. But I don't know what they know, because they don't say what needs addressing and you don't say anything about upgrading security as you upgrade the i* variations of the underlying protocols. (Maybe the SAM-4 pretty picture of the architecture needs to be updated to show the security boxes. But the SAM-5 proposal simply doesn't say what needs to be done, so i cnanto see if it is something simple or something difficult that could impact making storage accessible securely over the Internet.) > > Regarding SAM-5, the draft storm WG charter references SAM-4 > and not SAM-5 for a reason; SAM-5 is an out-of-scope moving > target. Understood. I was not suggesting we should try for SAM-5 compatibility. > FWIW, most SCSI (T10) security is not in the SAM > standards, but rather in the SPC-4 standard (under development). > For Fibre Channel (T11) security, see the FC-SP standard and > the FC-SP-2 standard (under development). > > That brings me to the T10 and T11 standards access concerns, > which are real and something I need to work on. INCITS, the > parent organization of T10 and T11, imposed new document > access restrictions within the past year. I need to work > with T10 and T11 on how to go about making the necessary > standards documents available to IETF participants, starting > with T10 (which meets next week). I do not intend to ask > the IESG for approval of the storm WG charter until the > document access concerns are resolved. > > Thanks, > --David > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, April 30, 2009 12:30 PM > > To: 'Lars Eggert'; 'Ersue, Mehmet (NSN - DE/Munich)' > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; Black, David; > > iesg@ietf.org; iesg@ietf.org; 'IAB' > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > Maintenance (storm) > > > > Hi, > > > > I found that having the discussion for the STORM BOF on the mailing > > lists for (three) concluded WGs made it a bit obscure. > > As far as I can tell by looking at those archives, there wasn't much > > discussion. > > I will also note that the announcement of the craetion of the storm > > list seems to be have been only announced to the lists of the three > > concluded WGs. So if you weren't involved in the three earlier WGs, > > you might not have seen the announcement. > > > > I do think Mehmet has a point that many IETF people may not > have been > > aware the discussion was happening. > > > > As an OPSDIR member and MIB Doctor, I have already > expressed concerns > > that operations and management is not being addressed in > the charter. > > The chair helpfully responded with a short list of management > > standards (SNIA SMI-S, SNIA SCSI HBA, INCITS FC HBA) that might help > > answer my questions. Unfortunately, I cannot access some of the > > documents referenced because they are not freely available. > If I read > > through a number of large standards I might be able to determine for > > myself what changes might need to be made to utilize the existing > > non-IETF standards to manage the updated IETF storage standards. I > > think I would rather see the WG consdier this and document > it, rather > > than me (and any other user of the IETF technologies) having to > > research this personally to know the answers. I would nto say my > > concerns have been addressed. > > > > As a SECDIR member, I have concerns that security may not be gettng > > addressed either, but it is hard for me to say that for sure since I > > cannot freely access the T10 and T11 documents that are the basis of > > the updates. I do not know whether the updated IETF storage > standards > > will utilize IETF standards for security or non-IETF stndards for > > security, or whether the WG is simply not going to address security > > issues since it is not mentioned in the charter. I note that the > > charter calls for updating to SAM-4 level, and that T10 is starting > > new work on SAM-5, explicitly to address security. So does that mean > > security will not be addressed in the STORM WG? > > > > I have not seen these discussions elsewhere. And Mehmet's concerns > > seem to be relevant to that point. > > > > Before the WG is created, I think the charter should be > explicit about > > the what the WG will do to address how these Internet > protocols should > > be operated and managed and secured. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > -----Original Message----- > > > From: ops-dir-bounces@ietf.org > > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Lars Eggert > > > Sent: Tuesday, April 28, 2009 12:44 PM > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; > > > Black_David@emc.com; iesg@ietf.org > > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage > > > Maintenance (storm) > > > > > > Hi, > > > > > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > unfortunately I missed the Storm BoF in SF. I also was not aware > > of > > > > the discussion on the maillists you mention. > > > > > > > > I made the experience that announcing a BoF maillist to IETF and > > > > forcing some discussion on this maillist with IETF member > > > > participation > > > > is a good way to show IESG that there is measurable > IETF community > > > > interest. > > > > > > as David said below, there was discussion on the > > > still-existing RDDP, > > > IPS and IMSS lists, and the BOF went - in my opinion - > very well. I > > > > > believe community interest has been demonstrated, which > is why we're > > > > > going forward with a charter proposal. > > > > > > > The huge amount of people in the session, which are sometimes > > > > occasionally in the room and vote, usually disappear when > > > it comes to > > > > maillist discussion. Also for our regular WG work the decisions > > have > > > > to be confirmed on the maillist. > > > > > > > > As I said I believe this is an important and necessary > > consolidation > > > > work but should be discussed and accepted first in the IETF > > > community. > > > > > > I don't quite know what to do with you comment. Are you > saying there > > > > > hasn't been sufficient discussion to go forward with the > chartering? > > > > > Or am I misunderstanding? > > > > > > I'll also note that the community obviously still has time to > > > comment > > > - the charter is in internal I* review at this time, > after which it > > > > > will go for public review. > > > > > > Lars > > > > > > > > > > > Cheers, > > > > Mehmet > > > > > > > > > > > >> -----Original Message----- > > > >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] > > > >> Sent: Tuesday, April 28, 2009 2:32 PM > > > >> To: Ersue, Mehmet (NSN - DE/Munich) > > > >> Cc: dromasca@avaya.com; Black_David@emc.com > > > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > >> Maintenance (storm) > > > >> > > > >> Mehmet, > > > >> > > > >> The storm list is completely new (it was only opened for people > > > >> to subscribe within the past few days). The storm BOF in San > > > >> Francisco was organized using the existing IPS, RDDP and IMSS > > > >> mailing lists. I suggest consulting the archives for those > > > >> lists, particularly for the IPS list, where you should find a > > > >> reasonable level of community interest. > > > >> > > > >> There is definite community interest in this work, and I have > > > >> author commitments for drafts for all six work items listed > > > >> in the charter - each of the "First version of" milestone > > > >> dates in the proposed charter is based on discussion with an > > > >> author or authors who believe that a first version of the draft > > > >> will be ready by that date. > > > >> > > > >> Thanks, > > > >> --David > > > >> ---------------------------------------------------- > > > >> David L. Black, Distinguished Engineer > > > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > >> black_david@emc.com Mobile: +1 (978) 394-7754 > > > >> ---------------------------------------------------- > > > >> > > > >>> -----Original Message----- > > > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > >>> Sent: Tuesday, April 28, 2009 6:33 AM > > > >>> To: Ersue, Mehmet (NSN - DE/Munich) > > > >>> Cc: Black, David > > > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > >>> Maintenance (storm) > > > >>> > > > >>> Mehmet, > > > >>> > > > >>> David Black ran the BOF in San Francisco. He should be able > > > >> to provide > > > >>> you information about the preparation work, level of > support and > > > >>> interest from the community and initial drafts. > > > >>> > > > >>> Thanks for looking into this and for asking the questions. > > > >>> > > > >>> Dan > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Ersue, Mehmet (NSN - DE/Munich) > > > >> [mailto:mehmet.ersue@nsn.com] > > > >>>> Sent: Tuesday, April 28, 2009 1:29 PM > > > >>>> To: Romascanu, Dan (Dan) > > > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > >>>> Maintenance (storm) > > > >>>> > > > >>>> > > > >>>> Hi Dan, > > > >>>> > > > >>>> I believe this is an important and necessary consolidation > > work. > > > >>>> > > > >>>> I might have missed the discussion on another maillist but > > > >>>> the storm maillist is pretty much new and I would have a > > > >>>> better feeling if there were some mail traffic showing the > > > >>>> interest of the community and/or an initial draft with an > > > >>>> issues list for the justification of a new WG. > > > >>>> > > > >>>> Cheers, > > > >>>> Mehmet > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: ops-dir-bounces@ietf.org > > > >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext > Romascanu, > > > >>>>> Dan (Dan) > > > >>>>> Sent: Monday, April 27, 2009 7:57 PM > > > >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org > > > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage > > > >>>> Maintenance (storm) > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -----Original Message----- > > > >>>>> From: iesg-bounces@ietf.org > [mailto:iesg-bounces@ietf.org] On > > > >>>>> Behalf Of > > > >>>>> IESG Secretary > > > >>>>> Sent: Monday, April 27, 2009 8:54 PM > > > >>>>> To: iesg@ietf.org; iab@iab.org > > > >>>>> Cc: black_david@emc.com > > > >>>>> Subject: Internal WG Review: STORage Maintenance (storm) > > > >>>>> > > > >>>>> A new IETF working group is being considered in the > Transport > > > >>>>> Area. The > > > >>>>> draft charter for this working group is provided below for > > > >>>> your review > > > >>>>> and comment. > > > >>>>> > > > >>>>> Review time is one week. > > > >>>>> > > > >>>>> The IETF Secretariat > > > >>>>> > > > >>>>> STORage Maintenance (storm) > > > >>>>> ---------------------------------- > > > >>>>> > > > >>>>> Last Modified: 2009-04-25 > > > >>>>> > > > >>>>> Current Status: Proposed Working Group > > > >>>>> > > > >>>>> Chairs: > > > >>>>> - David L. Black > > > >>>>> - tbd > > > >>>>> > > > >>>>> Transport Area Director(s): > > > >>>>> - Magnus Westerlund > > > >>>>> - Lars Eggert > > > >>>>> > > > >>>>> Transport Area Advisor: > > > >>>>> - Lars Eggert > > > >>>>> > > > >>>>> Mailing Lists: > > > >>>>> General Discussion: storm@ietf.org > > > >>>>> To Subscribe: storm-request@ietf.org > > > >>>>> In Body: (un)subscribe > > > >>>>> Archive: > http://www.ietf.org/mail-archive/web/storm/index.html > > > >>>>> > > > >>>>> Description of Working Group: > > > >>>>> > > > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data > > > >> Placement) > > > >>>>> working groups have produced a significant number of > > > >>>> storage protocols > > > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is significant > > > >>>> usage. The > > > >>>>> time has come to reflect feedback from implementation and > > > >>> usage into > > > >>>>> updated RFCs; this work may include: > > > >>>>> > > > >>>>> - Implementation-driven revisions and updates to existing > > > >>> protocols > > > >>>>> (i.e., updated RFCs that match the "running code"). > > > >>>>> > > > >>>>> - Interoperability reports as needed for the resulting > > > >>>>> revised protocols > > > >>>>> that are appropriate for Draft Standard RFC status. > > > >>>>> > > > >>>>> - Minor protocol changes or additions. Backwards > > > >> compatibility is > > > >>>>> required. > > > >>>>> > > > >>>>> Significant changes to the existing protocol standards are > > > >>>>> out of scope, > > > >>>>> including any work on version 2 of any of these protocols. > > > >>>>> > > > >>>>> Stability is critical to the usage of these protocols, so > > > >>> backwards > > > >>>>> compatibility with existing implementations will be a > > > >> requirement > > > >>>>> imposed on for all protocol changes and additions. Note > > > >>>> that this is a > > > >>>>> requirement for implementation compatibility - if it is the > > > >>>> case that > > > >>>>> all implementations of a protocol have done something > > > >>> different than > > > >>>>> what the RFC specifies, it is appropriate for a new RFC to > > > >>>>> document what > > > >>>>> the "running code" actually does and deprecate the > > > >> unused original > > > >>>>> behavior. > > > >>>>> > > > >>>>> Initial list of work items: > > > >>>>> > > > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), > > > >> 4850 (node > > > >>>>> architecture key) and 5048 (corrections/clarifications) > > > >>>> into one draft > > > >>>>> (3720bis), removing features that are not implemented in > > > >>>>> practice. This > > > >>>>> draft should be prepared so that it could become a Draft > > > >>>> Standard RFC, > > > >>>>> but it is up to the to decide whether to advance it to > > > >>>> Draft Standard. > > > >>>>> > > > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version > > > >> of the SCSI > > > >>>>> architecture) in a backwards-compatible fashion, as iSCSI > > > >>>> is currently > > > >>>>> based on SAM-2. This will be a separate draft from the > > > >>>> iSCSI update in > > > >>>>> the previous bullet. The Working group may add additional > > > >>>> minor useful > > > >>>>> iSCSI features to this draft. > > > >>>>> > > > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a > > > >>> precursor of the > > > >>>>> FCIP protocol in 2000, but this allocated number is not > > > >>>> used by FCIP. > > > >>>>> The working group will consider whether this > allocated number > > > >>>>> should be > > > >>>>> returned to IANA for future reallocation. > > > >>>>> > > > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be > > > >>>> deprecated > > > >>>>> (SHOULD NOT implement or use), as there are significant > > > >> technical > > > >>>>> problems with its specification, and moreover, only the > > Address > > > >>>>> Transparent mode of iFCP is in use. This will be done via a > > > >>>>> short draft > > > >>>>> that updates RFC 4172, and not via a complete rewrite of > > > >>> RFC 4172. A > > > >>>>> combined draft is expected that encompasses items > (3) and (4). > > > >>>>> > > > >>>>> (5) RDDP MPA: Good support for MPI applications requires a > > > >>>>> small update > > > >>>>> to the startup functionality to allow either end of the > > > >>>> connection to > > > >>>>> initiate. > > > >>>>> > > > >>>>> (6) iSER: Experience with Infiniband implementations suggest > > > >>>>> a few minor > > > >>>>> updates to reflect what has been done in practice. > > > >>>>> > > > >>>>> The working group is expected to maintain good working > > > >>> relationships > > > >>>>> with INCITS Technical Committee T10 (SCSI standards) and > > INCITS > > > >>>>> Technical Committee T11 (Fibre Channel standards) via > > > >> overlaps in > > > >>>>> membership as opposed to appointment of formal liaisons. > > > >>> The liaison > > > >>>>> process (including IAB appointment of a liaison or > > > >>>>> liaisons) remains available for use if needed. > > > >>>>> > > > >>>>> Goals and Milestones: > > > >>>>> > > > >>>>> June 2009 First version of FCIP protocol number and iFCP > > Address > > > >>>>> Translation mode draft > > > >>>>> > > > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new > > > >>>> features draft. > > > >>>>> > > > >>>>> Aug 2009 First version of RDDP MPA startup change draft > > > >>>>> > > > >>>>> Sep 2009 Working Group Last Call on FCIP protocol > > > >> number and iFCP > > > >>>>> address change draft > > > >>>>> > > > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) > > > >>>>> > > > >>>>> Oct 2009 First version of iSER update draft > > > >>>>> > > > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup > > > >> change draft. > > > >>>>> > > > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) > > > >>> new features > > > >>>>> draft. > > > >>>>> > > > >>>>> Feb 2010 Working Group Last Call on iSER update draft > > > >>>>> > > > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and > > > >> other) new > > > >>>>> features draft. > > > >>>>> > > > >>>>> April 2010 Working Group decision on whether to seek Draft > > > >>>>> Standard RFC > > > >>>>> status for the combined iSCSI draft (3720bis). [Note: > > > >>>>> decision may be made significantly before this date.] > > > >>>>> > > > >>>>> Sep 2010 Working Group Last Call on combined iSCSI > > > >> draft (3720bis) > > > >>>>> _______________________________________________ > > > >>>>> OPS-DIR mailing list > > > >>>>> OPS-DIR@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >> > > > > > > _______________________________________________ > > > OPS-DIR mailing list > > > OPS-DIR@ietf.org > > > https://www.ietf.org/mailman/listinfo/ops-dir > > > > > > > > > > From ietfdbh@comcast.net Fri May 1 08:43:01 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748DF28C18D for ; Fri, 1 May 2009 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 joqNt2XFKzaN for ; Fri, 1 May 2009 08:43:00 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 91D943A720E for ; Fri, 1 May 2009 08:43:00 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id mE1L1b00o17dt5G52FkL2T; Fri, 01 May 2009 15:44:20 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id mFkQ1b00b0UQ6dC3ZFkQlb; Fri, 01 May 2009 15:44:25 +0000 From: "David Harrington" To: , , References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> Date: Fri, 1 May 2009 11:44:23 -0400 Message-ID: <047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:43:01 -0000 Hi, I would like to probe an apparent inconsistency. > Let me start by acknowledging that David Harrington is right > about the absence of operations and management in the charter. > [...] I need to > revise the draft charter to include that. > [...] > That said, I am surprised by what appears to be an inference > that lack of mention of security in the charter implies that > security may not be addressed at all. All RFCs have to address > security considerations, making security something that every > IETF WG has to address, independent of whether security is > explicitly mentioned in the WG charter. If every WG charter > now has to have a "Security Considerations" section, there are > number of WG charters on the IETF web site that need updates > ... surely the IESG has better things to do ;-). So you are surprised by the inference that security may not be addressed because all RFCs have to address security considerations. You do not seem surprised by the same inference regarding OPS+MGMT. So if the IESG does not mandate an OPS+MGMT considerations section, just as they do for security, then in the absence of such a mandate it is not surprising to infer that management will not be addressed unless it is explicitly stated in the charter? Did I understand your responses correctly? dbh From Black_David@emc.com Fri May 1 09:15:07 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427FC3A6BBC; Fri, 1 May 2009 09:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 QBJP3pNFz2ZG; Fri, 1 May 2009 09:15:06 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4960B3A6B21; Fri, 1 May 2009 09:15:06 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41GGQuN014806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 12:16:27 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 12:16:18 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n41GGHCe024542; Fri, 1 May 2009 12:16:17 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 12:16:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 12:16:16 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> In-Reply-To: <047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TA References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> <047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> To: , , X-OriginalArrivalTime: 01 May 2009 16:16:17.0156 (UTC) FILETIME=[27EDEC40:01C9CA78] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:15:07 -0000 David, The source of the inconsistency is that the proposed STORM charter has a concrete omission in the OPS+MGMT area, namely an iSCSI MIB update, whereas I know of no corresponding concrete omission in the security area. IMHO, the charter needs an update to correct that omission. > So if the IESG does not mandate an OPS+MGMT considerations section, > just as they do for security, then in the absence of such a mandate > it is not surprising to infer that management will not be addressed > unless it is explicitly stated in the charter? No - I fully expect the OPS+MGMT ADs to use pointed "Discuss"es to ensure that any such issues are addressed, and a good WG chair is out ahead of this class of issue. This is not just about OPS+MGMT - by way of analogy, as a member of the Transport Directorate, I expect the Transport ADs to do likewise for congestion control issues, independent of whether congestion control is in a WG's charter or not (and a good WG chair is out ahead of congestion control issues before they cause "Discuss"es). Thanks, --David =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, May 01, 2009 11:44 AM > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > iab@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Hi, >=20 > I would like to probe an apparent inconsistency. >=20 > > Let me start by acknowledging that David Harrington is right > > about the absence of operations and management in the charter. > > [...] I need to > > revise the draft charter to include that.=20 > =20 > > [...] > > That said, I am surprised by what appears to be an inference > > that lack of mention of security in the charter implies that > > security may not be addressed at all. All RFCs have to address > > security considerations, making security something that every > > IETF WG has to address, independent of whether security is > > explicitly mentioned in the WG charter. If every WG charter > > now has to have a "Security Considerations" section, there are > > number of WG charters on the IETF web site that need updates > > ... surely the IESG has better things to do ;-). >=20 > So you are surprised by the inference that security may not be > addressed > because all RFCs have to address security considerations. > You do not seem surprised by the same inference regarding OPS+MGMT. > So if the IESG does not mandate an OPS+MGMT considerations section, > just=20 > as they do for security, then in the absence of such a mandate it is > not=20 > surprising to infer that management will not be addressed unless it is > explicitly stated in the charter? >=20 > Did I understand your responses correctly? >=20 > dbh >=20 >=20 >=20 From dromasca@avaya.com Fri May 1 10:11:40 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0823A6D18; Fri, 1 May 2009 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 2mQOhWVUqa0X; Fri, 1 May 2009 10:11:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 129463A684E; Fri, 1 May 2009 10:10:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238990400"; d="scan'208";a="169629387" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 May 2009 13:11:45 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 May 2009 13:11:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 19:11:27 +0200 Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDA= References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> From: "Romascanu, Dan (Dan)" To: , , , Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:11:41 -0000 David (B), DISCUSSes on the protocol documents are exactly at the oposite extremity of the IETF process. They are certainly a good tool to address issues when the document arrives at the IESG table for review and approval. However, the operational and manageability issues need to be addressed at each phase of the development of the protocol starting with the WG chartering phase which we are now in. Asking the questions that David (H) is asking about how the storage technology is managed over the Internet, looking at the MIB modules defined in the previous phase and assessing whether they meet the operational needs, looking whether other protocols may do a similar or better job, all these seem reasonable issues to discuss now and catch in the future charter. Even the fact that there seems to be lesser interest in doing further MIB work is an indication of some kind that we need to address.=20 Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Friday, May 01, 2009 7:16 PM > To: ietfdbh@comcast.net; lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org; Black_David@emc.com > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > David, >=20 > The source of the inconsistency is that the proposed STORM=20 > charter has a concrete omission in the OPS+MGMT area, namely=20 > an iSCSI MIB update, whereas I know of no corresponding=20 > concrete omission in the security area. IMHO, the charter=20 > needs an update to correct that omission. >=20 > > So if the IESG does not mandate an OPS+MGMT considerations section,=20 > > just as they do for security, then in the absence of such a=20 > mandate it=20 > > is not surprising to infer that management will not be addressed=20 > > unless it is explicitly stated in the charter? >=20 > No - I fully expect the OPS+MGMT ADs to use pointed=20 > "Discuss"es to ensure that any such issues are addressed, and=20 > a good WG chair is out ahead of this class of issue. This is=20 > not just about > OPS+MGMT - by way of analogy, as a member of the Transport > Directorate, I expect the Transport ADs to do likewise for=20 > congestion control issues, independent of whether congestion=20 > control is in a WG's charter or not (and a good WG chair is=20 > out ahead of congestion control issues before they cause "Discuss"es). >=20 > Thanks, > --David > =20 >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, May 01, 2009 11:44 AM > > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > > iab@ietf.org > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage Maintenance=20 > > (storm) > >=20 > > Hi, > >=20 > > I would like to probe an apparent inconsistency. > >=20 > > > Let me start by acknowledging that David Harrington is=20 > right about=20 > > > the absence of operations and management in the charter. > > > [...] I need to > > > revise the draft charter to include that.=20 > > =20 > > > [...] > > > That said, I am surprised by what appears to be an inference that=20 > > > lack of mention of security in the charter implies that=20 > security may=20 > > > not be addressed at all. All RFCs have to address security=20 > > > considerations, making security something that every IETF=20 > WG has to=20 > > > address, independent of whether security is explicitly=20 > mentioned in=20 > > > the WG charter. If every WG charter now has to have a "Security=20 > > > Considerations" section, there are number of WG charters=20 > on the IETF=20 > > > web site that need updates ... surely the IESG has better=20 > things to=20 > > > do ;-). > >=20 > > So you are surprised by the inference that security may not be=20 > > addressed because all RFCs have to address security considerations. > > You do not seem surprised by the same inference regarding OPS+MGMT. > > So if the IESG does not mandate an OPS+MGMT considerations section,=20 > > just as they do for security, then in the absence of such a=20 > mandate it=20 > > is not surprising to infer that management will not be addressed=20 > > unless it is explicitly stated in the charter? > >=20 > > Did I understand your responses correctly? > >=20 > > dbh > >=20 > >=20 > >=20 >=20 From Black_David@emc.com Fri May 1 10:26:44 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E123C3A6A12; Fri, 1 May 2009 10:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 rSqB1+3i5uJO; Fri, 1 May 2009 10:26:43 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 963BE3A6954; Fri, 1 May 2009 10:26:43 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41HRxYx012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 13:28:01 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 13:27:53 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n41HRr4V022318; Fri, 1 May 2009 13:27:53 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 13:27:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 13:27:51 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EA== References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> To: , , , X-OriginalArrivalTime: 01 May 2009 17:27:52.0956 (UTC) FILETIME=[286CFBC0:01C9CA82] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:26:45 -0000 Dan, I agree with almost everything you wrote (and I have a track record of addressing issues from other areas in WGs that I've run). OTOH, I have a concern here in that the M in STORM stands for "Maintenance" - there are a bunch of moderately sized updates and cleanup that need to be done to the protocol specs in this area. Rightly or wrongly, I perceive the direction of Dave H's questions as wanting to explore completely reworking storage-related management. While I like the idea of exploring that area in principle, I'm concerned that a maintenance-oriented proposed TSV WG may not be a particularly good forum for heavy-duty OPS+MGMT work. Let me suggest an OPS Directorate discussion as an alternative forum in which to make progress on this - I expect to be in Stockholm and would be happy to spend time on this in the meeting and/or hallway discussion. What do you think about this? Thanks, --David > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Friday, May 01, 2009 1:11 PM > To: Black, David; ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > David (B), >=20 > DISCUSSes on the protocol documents are exactly at the=20 > oposite extremity > of the IETF process. They are certainly a good tool to address issues > when the document arrives at the IESG table for review and approval. > However, the operational and manageability issues need to be addressed > at each phase of the development of the protocol starting with the WG > chartering phase which we are now in. Asking the questions that David > (H) is asking about how the storage technology is managed over the > Internet, looking at the MIB modules defined in the previous phase and > assessing whether they meet the operational needs, looking=20 > whether other > protocols may do a similar or better job, all these seem reasonable > issues to discuss now and catch in the future charter. Even the fact > that there seems to be lesser interest in doing further MIB work is an > indication of some kind that we need to address.=20 >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > > Behalf Of Black_David@emc.com > > Sent: Friday, May 01, 2009 7:16 PM > > To: ietfdbh@comcast.net; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > iesg@ietf.org; Black_David@emc.com > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > David, > >=20 > > The source of the inconsistency is that the proposed STORM=20 > > charter has a concrete omission in the OPS+MGMT area, namely=20 > > an iSCSI MIB update, whereas I know of no corresponding=20 > > concrete omission in the security area. IMHO, the charter=20 > > needs an update to correct that omission. > >=20 > > > So if the IESG does not mandate an OPS+MGMT=20 > considerations section,=20 > > > just as they do for security, then in the absence of such a=20 > > mandate it=20 > > > is not surprising to infer that management will not be addressed=20 > > > unless it is explicitly stated in the charter? > >=20 > > No - I fully expect the OPS+MGMT ADs to use pointed=20 > > "Discuss"es to ensure that any such issues are addressed, and=20 > > a good WG chair is out ahead of this class of issue. This is=20 > > not just about > > OPS+MGMT - by way of analogy, as a member of the Transport > > Directorate, I expect the Transport ADs to do likewise for=20 > > congestion control issues, independent of whether congestion=20 > > control is in a WG's charter or not (and a good WG chair is=20 > > out ahead of congestion control issues before they cause=20 > "Discuss"es). > >=20 > > Thanks, > > --David > > =20 > >=20 > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Friday, May 01, 2009 11:44 AM > > > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > > > iab@ietf.org > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance=20 > > > (storm) > > >=20 > > > Hi, > > >=20 > > > I would like to probe an apparent inconsistency. > > >=20 > > > > Let me start by acknowledging that David Harrington is=20 > > right about=20 > > > > the absence of operations and management in the charter. > > > > [...] I need to > > > > revise the draft charter to include that.=20 > > > =20 > > > > [...] > > > > That said, I am surprised by what appears to be an=20 > inference that=20 > > > > lack of mention of security in the charter implies that=20 > > security may=20 > > > > not be addressed at all. All RFCs have to address security=20 > > > > considerations, making security something that every IETF=20 > > WG has to=20 > > > > address, independent of whether security is explicitly=20 > > mentioned in=20 > > > > the WG charter. If every WG charter now has to have a=20 > "Security=20 > > > > Considerations" section, there are number of WG charters=20 > > on the IETF=20 > > > > web site that need updates ... surely the IESG has better=20 > > things to=20 > > > > do ;-). > > >=20 > > > So you are surprised by the inference that security may not be=20 > > > addressed because all RFCs have to address security=20 > considerations. > > > You do not seem surprised by the same inference regarding=20 > OPS+MGMT. > > > So if the IESG does not mandate an OPS+MGMT=20 > considerations section,=20 > > > just as they do for security, then in the absence of such a=20 > > mandate it=20 > > > is not surprising to infer that management will not be addressed=20 > > > unless it is explicitly stated in the charter? > > >=20 > > > Did I understand your responses correctly? > > >=20 > > > dbh > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 From dromasca@avaya.com Fri May 1 10:44:31 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795FD3A6C29; Fri, 1 May 2009 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 8BpLtGT8JnK1; Fri, 1 May 2009 10:44:30 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4ECE43A6BF2; Fri, 1 May 2009 10:44:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238990400"; d="scan'208";a="144660446" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2009 13:45:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 May 2009 13:45:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 19:45:26 +0200 Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAAAmSaA References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> From: "Romascanu, Dan (Dan)" To: , , , Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:44:31 -0000 David, Unless all the incremental changes you plan have no impact at all on operations and manageability I would prefer that the issues be brought up with the community that requested the formation of the WG and addressed in the charter rather than postponed for a future discussion in other frameworks (OPS-DIR would not be anyway the appropriate place, as this is mainly a review team providing advice to the OPS ADs). Not dealing with the manageability issues would mean that we create a delay between the evolution of the technology and the MIB modules for interoperable management. It would be OK to say management by SNMP is not deployed but then the MIB RFCs could be made Historical and something else recommended. It would be OK to write an Informational RFC that explains how storage is operationally deployed and managed over the Internet. It is not OK I think to ignore the issue.=20 Dan > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Friday, May 01, 2009 8:28 PM > To: Romascanu, Dan (Dan); ietfdbh@comcast.net;=20 > lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org; Black_David@emc.com > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Dan, >=20 > I agree with almost everything you wrote (and I have a track=20 > record of addressing issues from other areas in WGs that I've=20 > run). OTOH, I have a concern here in that the M in STORM=20 > stands for "Maintenance" - there are a bunch of moderately=20 > sized updates and cleanup that need to be done to the=20 > protocol specs in this area. Rightly or wrongly, I perceive=20 > the direction of Dave H's questions as wanting to explore=20 > completely reworking storage-related management. >=20 > While I like the idea of exploring that area in principle,=20 > I'm concerned that a maintenance-oriented proposed TSV WG may=20 > not be a particularly good forum for heavy-duty OPS+MGMT=20 > work. Let me suggest an OPS Directorate discussion as an=20 > alternative forum in which to make progress on this - I=20 > expect to be in Stockholm and would be happy to spend time on=20 > this in the meeting and/or hallway discussion. What do you=20 > think about this? >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Friday, May 01, 2009 1:11 PM > > To: Black, David; ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > > mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > iesg@ietf.org > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage Maintenance=20 > > (storm) > >=20 > > David (B), > >=20 > > DISCUSSes on the protocol documents are exactly at the oposite=20 > > extremity of the IETF process. They are certainly a good tool to=20 > > address issues when the document arrives at the IESG table=20 > for review=20 > > and approval. > > However, the operational and manageability issues need to=20 > be addressed=20 > > at each phase of the development of the protocol starting=20 > with the WG=20 > > chartering phase which we are now in. Asking the questions=20 > that David > > (H) is asking about how the storage technology is managed over the=20 > > Internet, looking at the MIB modules defined in the=20 > previous phase and=20 > > assessing whether they meet the operational needs, looking whether=20 > > other protocols may do a similar or better job, all these seem=20 > > reasonable issues to discuss now and catch in the future=20 > charter. Even=20 > > the fact that there seems to be lesser interest in doing=20 > further MIB=20 > > work is an indication of some kind that we need to address. > >=20 > > Dan > >=20 > >=20 > > > -----Original Message----- > > > From: iesg-bounces@ietf.org=20 > [mailto:iesg-bounces@ietf.org] On Behalf=20 > > > Of Black_David@emc.com > > > Sent: Friday, May 01, 2009 7:16 PM > > > To: ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > mehmet.ersue@nsn.com > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > > iesg@ietf.org; Black_David@emc.com > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance=20 > > > (storm) > > >=20 > > > David, > > >=20 > > > The source of the inconsistency is that the proposed=20 > STORM charter=20 > > > has a concrete omission in the OPS+MGMT area, namely an iSCSI MIB=20 > > > update, whereas I know of no corresponding concrete=20 > omission in the=20 > > > security area. IMHO, the charter needs an update to correct that=20 > > > omission. > > >=20 > > > > So if the IESG does not mandate an OPS+MGMT > > considerations section, > > > > just as they do for security, then in the absence of such a > > > mandate it > > > > is not surprising to infer that management will not be=20 > addressed=20 > > > > unless it is explicitly stated in the charter? > > >=20 > > > No - I fully expect the OPS+MGMT ADs to use pointed=20 > "Discuss"es to=20 > > > ensure that any such issues are addressed, and a good WG chair is=20 > > > out ahead of this class of issue. This is not just about > > > OPS+MGMT - by way of analogy, as a member of the Transport > > > Directorate, I expect the Transport ADs to do likewise for=20 > > > congestion control issues, independent of whether=20 > congestion control=20 > > > is in a WG's charter or not (and a good WG chair is out ahead of=20 > > > congestion control issues before they cause > > "Discuss"es). > > >=20 > > > Thanks, > > > --David > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Friday, May 01, 2009 11:44 AM > > > > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > > > > iab@ietf.org > > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > Maintenance > > > > (storm) > > > >=20 > > > > Hi, > > > >=20 > > > > I would like to probe an apparent inconsistency. > > > >=20 > > > > > Let me start by acknowledging that David Harrington is > > > right about > > > > > the absence of operations and management in the charter. > > > > > [...] I need to > > > > > revise the draft charter to include that.=20 > > > > =20 > > > > > [...] > > > > > That said, I am surprised by what appears to be an > > inference that > > > > > lack of mention of security in the charter implies that > > > security may > > > > > not be addressed at all. All RFCs have to address security=20 > > > > > considerations, making security something that every IETF > > > WG has to > > > > > address, independent of whether security is explicitly > > > mentioned in > > > > > the WG charter. If every WG charter now has to have a > > "Security > > > > > Considerations" section, there are number of WG charters > > > on the IETF > > > > > web site that need updates ... surely the IESG has better > > > things to > > > > > do ;-). > > > >=20 > > > > So you are surprised by the inference that security may not be=20 > > > > addressed because all RFCs have to address security > > considerations. > > > > You do not seem surprised by the same inference regarding > > OPS+MGMT. > > > > So if the IESG does not mandate an OPS+MGMT > > considerations section, > > > > just as they do for security, then in the absence of such a > > > mandate it > > > > is not surprising to infer that management will not be=20 > addressed=20 > > > > unless it is explicitly stated in the charter? > > > >=20 > > > > Did I understand your responses correctly? > > > >=20 > > > > dbh > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 From dromasca@avaya.com Fri May 1 12:18:28 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19043A691D; Fri, 1 May 2009 12:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] 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 soUy03ovqHyI; Fri, 1 May 2009 12:18:27 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D7A5C3A6B82; Fri, 1 May 2009 12:18:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238990400"; d="scan'208";a="160109256" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 May 2009 15:19:44 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 May 2009 15:19:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 21:19:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for May 7, 2009 Telechat Thread-Index: AcnJ6fXwkkHGvmBrTk6rLche5FkltwApzUvA From: "Romascanu, Dan (Dan)" To: , , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for May 7, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:18:29 -0000 Please find below the preliminary agenda of the May 7 telechat. Please review the relevant documents and WG charters brought up for the IESG approval and send me your questions, comments, and concerns before 5/6 COB the latest.=20 Thanks and Regards, Dan =20 INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the May 7, 2009 IESG Teleconference This agenda was generated at 15:34:18 EDT, April 30, 2009 Web version of this agenda can be found at: http://www.ietf.org/IESG/agenda.html =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcpsecure-11.txt Improving TCP's Robustness to Blind In-Window Attacks (Proposed Standard) -=20 1 of 11=20 Note: IESG: Please read the Document Shepherd Writeup, we need to discuss=20 the "Updates: 793" issue.=20 Token: Lars Eggert o draft-ietf-tsvwg-rsvp-proxy-proto-08.txt RSVP Extensions for Path-Triggered RSVP Receiver Proxy (Proposed Standard)=20 - 2 of 11=20 Note: Please read the informational document=20 draft-ietf-tsvwg-rsvp-proxy-approaches before this one!=20 Token: Magnus Westerlund o draft-ietf-mpls-p2mp-te-mib-09.txt Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic=20 Engineering (TE) Management Information Base (MIB) module (Proposed=20 Standard) - 3 of 11=20 Token: Ross Callon o draft-ietf-radext-design-07.txt RADIUS Design Guidelines (BCP) - 4 of 11=20 Token: Dan Romascanu o draft-ietf-mipshop-mos-dhcp-options-13.txt Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE=20 802.21 Mobility Services (MoS) Discovery (Proposed Standard) - 5 of 11 =20 Token: Jari Arkko o draft-ietf-isms-tmsm-17.txt Transport Subsystem for the Simple Network Management Protocol (SNMP) (Proposed Standard) - 6 of 11=20 Token: Pasi Eronen o draft-ietf-isms-transport-security-model-13.txt Transport Security Model for SNMP (Proposed Standard) - 7 of 11=20 Token: Pasi Eronen o draft-ietf-isms-secshell-16.txt Secure Shell Transport Model for SNMP (Proposed Standard) - 8 of 11=20 Token: Pasi Eronen o draft-ietf-isms-radius-usage-06.txt Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models (Proposed Standard) - 9=20 of 11=20 Token: Pasi Eronen o draft-ietf-dccp-serv-codes-09.txt The DCCP Service Code (Proposed Standard) - 10 of 11=20 Token: Lars Eggert o draft-ietf-mipshop-rfc5268bis-01.txt Mobile IPv6 Fast Handovers (Proposed Standard) - 11 of 11=20 Token: Jari Arkko 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-thomson-beep-async-02.txt Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)=20 (Proposed Standard) - 1 of 2=20 Note: Chris Newman is the document shepherd..=20 Token: Alexey Melnikov o draft-ncook-urlauth-accessid-02.txt Internet Message Access Protocol (IMAP) - URL Access Identifier Extension=20 (Proposed Standard) - 2 of 2=20 Note: Eric Burger is the document shepherd. This document is a Normative=20 dependency for a Lemonade WG document, updating another Lemonade document..=20 Token: Alexey Melnikov 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-tcpm-ecnsyn-08.txt Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK=20 Packets (Experimental) - 1 of 5=20 Token: Lars Eggert o draft-ietf-lemonade-notifications-10.txt Lemonade Notifications Architecture (Informational) - 2 of 5=20 Note: Eric Burger is the document shepherd.=20 Token: Alexey Melnikov o draft-ietf-openpgp-camellia-04.txt The Camellia Cipher in OpenPGP (Informational) - 3 of 5=20 Note: Derek Atkins has agreed to shepherd=20 Token: Tim Polk o draft-ietf-roll-indus-routing-reqs-05.txt Industrial Routing Requirements in Low Power and Lossy Networks=20 (Informational) - 4 of 5=20 Note: This I-D was updated after IETF last call to synchronise with IESG=20 review comments made for draft-ietf-roll-urban-routing-reqs. It also pickes=20 up GenArt review coments.=20 Token: Adrian Farrel o draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt RSVP Proxy Approaches (Informational) - 5 of 5=20 Note: Read this before the Protocol document=20 Token: Magnus Westerlund 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-p2pi-cooper-workshop-report-01.txt Report from the IETF workshop on P2P Infrastructure, May 28, 2008=20 (Informational) - 1 of 1=20 Token: Cullen Jennings 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-brusilovsky-pak-10.txt Password-Authenticated Diffie-Hellman Exchange (PAK) (Informational) - 1 of=20 2=20 Token: Tim Polk o draft-templin-isatapv4-02.txt Transmission of IPv4 Packets over ISATAP Interfaces (Informational) - 2 of=20 2=20 Token: Jari Arkko 3.3.2 Returning Item o draft-saleem-msml-08.txt Media Server Markup Language (MSML) (Informational) - 1 of 1=20 Token: Robert Sparks 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Yet Another Mail (yam) - 1 of 3 Token: Alexey Melnikov o STORage Maintenance (storm) - 2 of 3 Token: Lars Eggert o Extensible Messaging and Presence Protocol (xmpp) - 3 of 3 Token: Cullen Jennings 4.1.2 Proposed for Approval o Open Authentication Protocol (oauth) - 1 of 1 Token: Lisa Dusseault 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From Black_David@emc.com Fri May 1 12:30:32 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA89428C1A7; Fri, 1 May 2009 12:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 lT+yrsXCVzoF; Fri, 1 May 2009 12:30:31 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F17EA28C1E5; Fri, 1 May 2009 12:30:30 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41JVnPF028956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 15:31:50 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 15:31:40 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n41JVad5008504; Fri, 1 May 2009 15:31:39 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 15:31:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 15:31:22 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB5CF@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAAAmSaAAANv/yA= References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> To: , , , X-OriginalArrivalTime: 01 May 2009 19:31:39.0285 (UTC) FILETIME=[72DCDC50:01C9CA93] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:30:33 -0000 Dan, I think we should distinguish two topics: > Unless all the incremental changes you plan have no impact at all on > operations and manageability I would prefer that the issues be brought > up with the community that requested the formation of the WG and > addressed in the charter rather than postponed for a future discussion > in other frameworks (OPS-DIR would not be anyway the appropriate place, > as this is mainly a review team providing advice to the OPS ADs). Not > dealing with the manageability issues would mean that we create a delay > between the evolution of the technology and the MIB modules for > interoperable management. I agree with this, and it's my fault that the storm charter draft fails to mention the need to update at least the iSCSI MIB RFC. There may be a few additional MIBs that need attention - I'll check on this. > It would be OK to say management by SNMP is > not deployed but then the MIB RFCs could be made Historical and > something else recommended. It would be OK to write an Informational RFC > that explains how storage is operationally deployed and managed over the > Internet. It is not OK I think to ignore the issue.=20 This is a much broader topic, as it potentially affects something like 15 MIB RFCs (produced by the ips and imss WGs), and involves a *lot* of non-IETF technology. I believe that most of these MIBs are in use for various things (e.g., monitoring). It is only this broader topic that I am suggesting might benefit from some OPS Directorate discussion. Thanks, --David > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Friday, May 01, 2009 1:45 PM > To: Black, David; ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > David, >=20 > Unless all the incremental changes you plan have no impact at all on > operations and manageability I would prefer that the issues be brought > up with the community that requested the formation of the WG and > addressed in the charter rather than postponed for a future discussion > in other frameworks (OPS-DIR would not be anyway the=20 > appropriate place, > as this is mainly a review team providing advice to the OPS ADs). Not=20 > dealing with the manageability issues would mean that we=20 > create a delay > between the evolution of the technology and the MIB modules for > interoperable management. It would be OK to say management by SNMP is > not deployed but then the MIB RFCs could be made Historical and > something else recommended. It would be OK to write an=20 > Informational RFC > that explains how storage is operationally deployed and=20 > managed over the > Internet. It is not OK I think to ignore the issue.=20 >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > > Sent: Friday, May 01, 2009 8:28 PM > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net;=20 > > lars.eggert@nokia.com; mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > iesg@ietf.org; Black_David@emc.com > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > Dan, > >=20 > > I agree with almost everything you wrote (and I have a track=20 > > record of addressing issues from other areas in WGs that I've=20 > > run). OTOH, I have a concern here in that the M in STORM=20 > > stands for "Maintenance" - there are a bunch of moderately=20 > > sized updates and cleanup that need to be done to the=20 > > protocol specs in this area. Rightly or wrongly, I perceive=20 > > the direction of Dave H's questions as wanting to explore=20 > > completely reworking storage-related management. > >=20 > > While I like the idea of exploring that area in principle,=20 > > I'm concerned that a maintenance-oriented proposed TSV WG may=20 > > not be a particularly good forum for heavy-duty OPS+MGMT=20 > > work. Let me suggest an OPS Directorate discussion as an=20 > > alternative forum in which to make progress on this - I=20 > > expect to be in Stockholm and would be happy to spend time on=20 > > this in the meeting and/or hallway discussion. What do you=20 > > think about this? > >=20 > > Thanks, > > --David > >=20 > >=20 > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Friday, May 01, 2009 1:11 PM > > > To: Black, David; ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > > > mehmet.ersue@nsn.com > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > > iesg@ietf.org > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance=20 > > > (storm) > > >=20 > > > David (B), > > >=20 > > > DISCUSSes on the protocol documents are exactly at the oposite=20 > > > extremity of the IETF process. They are certainly a good tool to=20 > > > address issues when the document arrives at the IESG table=20 > > for review=20 > > > and approval. > > > However, the operational and manageability issues need to=20 > > be addressed=20 > > > at each phase of the development of the protocol starting=20 > > with the WG=20 > > > chartering phase which we are now in. Asking the questions=20 > > that David > > > (H) is asking about how the storage technology is managed=20 > over the=20 > > > Internet, looking at the MIB modules defined in the=20 > > previous phase and=20 > > > assessing whether they meet the operational needs,=20 > looking whether=20 > > > other protocols may do a similar or better job, all these seem=20 > > > reasonable issues to discuss now and catch in the future=20 > > charter. Even=20 > > > the fact that there seems to be lesser interest in doing=20 > > further MIB=20 > > > work is an indication of some kind that we need to address. > > >=20 > > > Dan > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: iesg-bounces@ietf.org=20 > > [mailto:iesg-bounces@ietf.org] On Behalf=20 > > > > Of Black_David@emc.com > > > > Sent: Friday, May 01, 2009 7:16 PM > > > > To: ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > > mehmet.ersue@nsn.com > > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > > > iesg@ietf.org; Black_David@emc.com > > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance=20 > > > > (storm) > > > >=20 > > > > David, > > > >=20 > > > > The source of the inconsistency is that the proposed=20 > > STORM charter=20 > > > > has a concrete omission in the OPS+MGMT area, namely an=20 > iSCSI MIB=20 > > > > update, whereas I know of no corresponding concrete=20 > > omission in the=20 > > > > security area. IMHO, the charter needs an update to=20 > correct that=20 > > > > omission. > > > >=20 > > > > > So if the IESG does not mandate an OPS+MGMT > > > considerations section, > > > > > just as they do for security, then in the absence of such a > > > > mandate it > > > > > is not surprising to infer that management will not be=20 > > addressed=20 > > > > > unless it is explicitly stated in the charter? > > > >=20 > > > > No - I fully expect the OPS+MGMT ADs to use pointed=20 > > "Discuss"es to=20 > > > > ensure that any such issues are addressed, and a good=20 > WG chair is=20 > > > > out ahead of this class of issue. This is not just about > > > > OPS+MGMT - by way of analogy, as a member of the Transport > > > > Directorate, I expect the Transport ADs to do likewise for=20 > > > > congestion control issues, independent of whether=20 > > congestion control=20 > > > > is in a WG's charter or not (and a good WG chair is out=20 > ahead of=20 > > > > congestion control issues before they cause > > > "Discuss"es). > > > >=20 > > > > Thanks, > > > > --David > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > > > Sent: Friday, May 01, 2009 11:44 AM > > > > > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > > > > > iab@ietf.org > > > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > Maintenance > > > > > (storm) > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I would like to probe an apparent inconsistency. > > > > >=20 > > > > > > Let me start by acknowledging that David Harrington is > > > > right about > > > > > > the absence of operations and management in the charter. > > > > > > [...] I need to > > > > > > revise the draft charter to include that.=20 > > > > > =20 > > > > > > [...] > > > > > > That said, I am surprised by what appears to be an > > > inference that > > > > > > lack of mention of security in the charter implies that > > > > security may > > > > > > not be addressed at all. All RFCs have to address security=20 > > > > > > considerations, making security something that every IETF > > > > WG has to > > > > > > address, independent of whether security is explicitly > > > > mentioned in > > > > > > the WG charter. If every WG charter now has to have a > > > "Security > > > > > > Considerations" section, there are number of WG charters > > > > on the IETF > > > > > > web site that need updates ... surely the IESG has better > > > > things to > > > > > > do ;-). > > > > >=20 > > > > > So you are surprised by the inference that security=20 > may not be=20 > > > > > addressed because all RFCs have to address security > > > considerations. > > > > > You do not seem surprised by the same inference regarding > > > OPS+MGMT. > > > > > So if the IESG does not mandate an OPS+MGMT > > > considerations section, > > > > > just as they do for security, then in the absence of such a > > > > mandate it > > > > > is not surprising to infer that management will not be=20 > > addressed=20 > > > > > unless it is explicitly stated in the charter? > > > > >=20 > > > > > Did I understand your responses correctly? > > > > >=20 > > > > > dbh > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 From ietfdbh@comcast.net Fri May 1 12:32:37 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB1A3A6CB2 for ; Fri, 1 May 2009 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] 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 dMpnYXXgKLaN for ; Fri, 1 May 2009 12:32:36 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 2ECC63A6BF4 for ; Fri, 1 May 2009 12:32:36 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id mC6G1b0360Fqzac5BKa0oa; Fri, 01 May 2009 19:34:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id mKaE1b0050UQ6dC3UKaEQL; Fri, 01 May 2009 19:34:15 +0000 From: "David Harrington" To: , , , References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> Date: Fri, 1 May 2009 15:33:58 -0400 Message-ID: <049801c9ca93$c67e50a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAADjTbA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:32:37 -0000 Hi David (B), > Dan, > > I agree with almost everything you wrote (and I have a track > record of addressing issues from other areas in WGs that I've > run). OTOH, I have a concern here in that the M in STORM > stands for "Maintenance" - there are a bunch of moderately > sized updates and cleanup that need to be done to the protocol > specs in this area. Rightly or wrongly, I perceive the direction > of Dave H's questions as wanting to explore completely reworking > storage-related management. > Actually, I think that is partially right and partially wrong. I do not know how large the differences are between the SAM-2 architectural model and the SAM-4 architectural model, but I assume there are some significant differences that will be done as part of the STORM "maintenance". The IETF has had a significant change in its philosophy of operations and management. When Randy Bush became an AD, he pushed hard to make the IETF understand that "write a MIB" was not a good solution for real-world management of Internet technologies. As a result the IETF started working on standardizing additional protocols for management, such as syslog, netconf, and ipfix. Basically, the IETF architecture/framework was changed. We went from having a single MIB for all management purposes (and effectively one protocol that accessed it) to multiple purpose-driven management protocols. IETF did this because it was "time to reflect feedback from implementation and usage". If we are going to do maintenance to reflect the updated SAM architecture, then I think we should also reflect the updated IETF Management Framework. I do not think it makes sense to blindly update the MIB modules without considering whether MIB modules are still considered the best current practice for all forms of Internet management. If the Internet storage industry has decided that SMI-S and T10 HBA and T11 HBA make more sense for managing Internet storage than SNMP and MIB modules, then, as the charter says, "The time has come to reflect feedback from implementation and usage into updated RFCs". If syslog and snmp traps are used widely for reporting events, the updated RFCs should reflect that. I do not propose that we develop Netconf/netmod modules, or that we develop new SDEs for the syslog protocol. That can always be done as part of version 2 of any protocols, or even done as separate tasks. OTOH, if updating to reflect SAM-4 is lees about "feedback from implementation and usage" and more about being consistent with emerging T10/T11 standards, then I think the IETF storage technology documents should RECOMMEND the IETF Proposed Standard syslog for logging, and the Proposed Standard netconf for configuration, and the Proposed Standard ipfix for information on IP flows, and SNMPv3 for monitoring, when these standards-track protocols are appropriate, since they are now part of the updated IETF architecture. So I think the storage protocol RFCs should have their management updated only to the degree of updating the RFCs to reflect implementation and usage, and to reflect the updated IETF management framework. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From dromasca@avaya.com Fri May 1 13:13:16 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FC73A6F7C; Fri, 1 May 2009 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] 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 U9sVkHQ5jWEE; Fri, 1 May 2009 13:13:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3029E3A7097; Fri, 1 May 2009 13:12:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238990400"; d="scan'208";a="144672215" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2009 16:13:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 May 2009 16:13:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 22:13:27 +0200 Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB5CF@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAAAmSaAAANv/yAAAh6KoA== References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com><9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB5CF@CORPUSMX80A.corp.emc.com> From: "Romascanu, Dan (Dan)" To: , , , Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:13:16 -0000 David, See in-line.=20 Regards, Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Friday, May 01, 2009 10:31 PM > To: Romascanu, Dan (Dan); ietfdbh@comcast.net;=20 > lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org; Black_David@emc.com > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Dan, >=20 > I think we should distinguish two topics: >=20 > > Unless all the incremental changes you plan have no impact=20 > at all on=20 > > operations and manageability I would prefer that the issues=20 > be brought=20 > > up with the community that requested the formation of the WG and=20 > > addressed in the charter rather than postponed for a future=20 > discussion=20 > > in other frameworks (OPS-DIR would not be anyway the appropriate > place, > > as this is mainly a review team providing advice to the OPS=20 > ADs). Not=20 > > dealing with the manageability issues would mean that we create a > delay > > between the evolution of the technology and the MIB modules for=20 > > interoperable management. >=20 > I agree with this, and it's my fault that the storm charter=20 > draft fails to mention the need to update at least the iSCSI MIB RFC. > There may be a few additional MIBs that need attention - I'll=20 > check on this. >=20 This looks good.=20 > > It would be OK to say management by SNMP is not deployed=20 > but then the=20 > > MIB RFCs could be made Historical and something else=20 > recommended. It=20 > > would be OK to write an Informational > RFC > > that explains how storage is operationally deployed and managed over > the > > Internet. It is not OK I think to ignore the issue.=20 >=20 > This is a much broader topic, as it potentially affects=20 > something like 15 MIB RFCs (produced by the ips and imss=20 > WGs), and involves a *lot* of non-IETF technology. I believe=20 > that most of these MIBs are in use for various things (e.g.,=20 > monitoring). It is only this broader topic that I am=20 > suggesting might benefit from some OPS Directorate discussion. Fine with this. Yet, it may be not necessarily an OPS-DIR discussion, but maybe one for the open OPSAREA meeting, so that it can reach a broader audience.=20 Dan =20 >=20 > Thanks, > --David >=20 From Black_David@emc.com Fri May 1 14:30:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A52E3A69B0; Fri, 1 May 2009 14:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mDkvBxacJ87U; Fri, 1 May 2009 14:30:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 6236A3A679F; Fri, 1 May 2009 14:30:26 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41LVhd2027424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 17:31:45 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 17:31:32 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n41LVVcI013126; Fri, 1 May 2009 17:31:31 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 17:31:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 17:31:09 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB66C@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAAAmSaAAANv/yAAAh6KoAACv1BQ References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com><9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB5CF@CORPUSMX80A.corp.emc.com> To: , , , X-OriginalArrivalTime: 01 May 2009 21:31:31.0331 (UTC) FILETIME=[31A7FD30:01C9CAA4] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:30:27 -0000 Dan, Many thanks - I think I may have just volunteered myself for an OPSAREA time slot in Stockholm ... Thanks, --David =20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Friday, May 01, 2009 4:13 PM > To: Black, David; ietfdbh@comcast.net; lars.eggert@nokia.com;=20 > mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 >=20 > David, >=20 > See in-line.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > > Behalf Of Black_David@emc.com > > Sent: Friday, May 01, 2009 10:31 PM > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net;=20 > > lars.eggert@nokia.com; mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iab@ietf.org;=20 > > iesg@ietf.org; Black_David@emc.com > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > Dan, > >=20 > > I think we should distinguish two topics: > >=20 > > > Unless all the incremental changes you plan have no impact at all on=20 > > > operations and manageability I would prefer that the issues be brought=20 > > > up with the community that requested the formation of the WG and=20 > > > addressed in the charter rather than postponed for a future discussion=20 > > > in other frameworks (OPS-DIR would not be anyway the appropriate place, > > > as this is mainly a review team providing advice to the OPS ADs). Not=20 > > > dealing with the manageability issues would mean that we create a delay > > > between the evolution of the technology and the MIB modules for=20 > > > interoperable management. > >=20 > > I agree with this, and it's my fault that the storm charter=20 > > draft fails to mention the need to update at least the iSCSI MIB RFC. > > There may be a few additional MIBs that need attention - I'll=20 > > check on this. >=20 > This looks good.=20 >=20 > > > It would be OK to say management by SNMP is not deployed but then the=20 > > > MIB RFCs could be made Historical and something else recommended. It=20 > > > would be OK to write an Informational RFC > > > that explains how storage is operationally deployed and managed over > > > the Internet. It is not OK I think to ignore the issue.=20 > >=20 > > This is a much broader topic, as it potentially affects=20 > > something like 15 MIB RFCs (produced by the ips and imss=20 > > WGs), and involves a *lot* of non-IETF technology. I believe=20 > > that most of these MIBs are in use for various things (e.g.,=20 > > monitoring). It is only this broader topic that I am=20 > > suggesting might benefit from some OPS Directorate discussion. >=20 > Fine with this. Yet, it may be not necessarily an OPS-DIR discussion, > but maybe one for the open OPSAREA meeting, so that it can reach a > broader audience.=20 >=20 > Dan > =20 > >=20 > > Thanks, > > --David > >=20 >=20 >=20 >=20 From Black_David@emc.com Fri May 1 14:33:28 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740083A69B0; Fri, 1 May 2009 14:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 k-gN4uaGGHlj; Fri, 1 May 2009 14:33:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id AE3343A68C7; Fri, 1 May 2009 14:33:25 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41LYkem029729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 17:34:46 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 17:34:36 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n41LYXaQ017030; Fri, 1 May 2009 17:34:33 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 17:34:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 17:34:01 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB670@CORPUSMX80A.corp.emc.com> In-Reply-To: <046701c9ca66$192b68c0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAIQ1s8AAKFJSA References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> <046701c9ca66$192b68c0$0600a8c0@china.huawei.com> To: , , X-OriginalArrivalTime: 01 May 2009 21:34:33.0238 (UTC) FILETIME=[9E14CB60:01C9CAA4] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:33:28 -0000 David, [ ... MIB & management discussion snipped, as Dan (AD) and I are in rough agreement on how to move forward on those topics ...] > I did not overlook that you would need to deal with Security > Considerations. >=20 > I did overlook RFC3723. There are lots of documents related to iSCSI=20 > and iFCP and FCIP and iSNS and ... I simply haven't had time to study > all of them. I'll add some mention of RFC 3723 to the proposed charter. > The problem I have is that I could not look at the documents from INCITS=20 > to determine the status of security for SCSI/iSCSI and FC/FCIP, etc.=20 I wish you'd asked where to look for this information first, as I've done a fair amount of work on security for both of these technologies. FWIW, I also do security work in the IETF - RFC 5282 is a recent example. For the status of security in SCSI and FC, the two documents to look at are the working drafts of the SPC-4 and FC-SP-2 standards. Both of these documents are publicly available, but (obviously) the contents of each standard will change as the work progresses: T10 SPC-4 Revision 18: http://www.t10.org/cgi-bin/ac.pl?t=3Df&f=3Dspc4r18.pdf T11 FC-SP-2 Version 2: http://www.t11.org/ftp/t11/pub/fc/sp-2/08-586v0.pdf In addition, all of the proposal documents for both standards efforts are publicly available (important for FC-SP-2, as there is a lot of work that's not reflected in the current draft). I have been a significant technical contributor to both standards and would be happy to answer any questions that you have about them. Almost everything in these standards is above the level of the IETF storage protocols and hence out of scope for the proposed STORM WG (aside from being referenced if/as appropriate). > INCITS did make public their intention to update SAM-4 to address > security. Apparently they think there is something that needs > addressing. But I don't know what they know, because they don't > say what needs addressing=20 Different organizations do things in different ways, and that level of summation is not uncommon in INCITS project proposals (in contrast, IETF WG charters tend to have a lot more details). As an active member of T10 who works on security, my understanding is that much of the explanation is: - SAM-4 doesn't say anything about security (believe it or not, the word "security" does not occur in the standard). - There is significant security functionality coming in SPC-4 (cf. the draft referenced above). - SAM-5 should be aligned with SPC-4, necessitating some security additions to the SCSI architecture. See the SPC-4 draft for some idea of what's likely to be coming. Thanks, --David =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, May 01, 2009 10:07 AM > To: Black, David; lars.eggert@nokia.com; mehmet.ersue@nsn.com > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > iab@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Hi, > inline.=20 >=20 > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > > Sent: Thursday, April 30, 2009 7:02 PM > > To: ietfdbh@comcast.net; lars.eggert@nokia.com; mehmet.ersue@nsn.com > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; iesg@ietf.org;=20 > > iab@ietf.org; Black_David@emc.com > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > Let me start by acknowledging that David Harrington is right > > about the absence of operations and management in the charter. > > At a minimum, the new iSCSI features strongly suggest an > > updated version of the iSCSI MIB (RFC 4544), and I need to > > revise the draft charter to include that. If David Harrington > > is willing to serve as a technical advisor to facilitate this > > update, that would be helpful. >=20 > Part of my concern is whether SNMP MIBs are the correct answer for > storage management.=20 > I do not know the answer to the question. Much of the charter > discusses bringing the=20 > IETF storage standards into compliance with implementation/deployment > reality. >=20 > I think the WG should also consider how to bring the storage MIBs into > compliance with > implementation/deployment reality. At a minimum, if new features are > added to the IETF storage > stanards, then the MIBs should also be updated. (I'll check with my > bosses to see if > they will support my acting as MIB/OPS technical advisor.) >=20 > But if the storage MIBs are not being used, and other management > standards are used for managing storage, > then maybe the IETF needs to acknowldge that reality and have our > standards accommodate that. >=20 > >=20 > > OTOH, I disagree with the suggestion that the WG "consider > > and document" ... "what changes might need to be made to > > utilize the existing non-IETF standards to manage the updated > > IETF storage standards". IMHO, it is usually better to > > communicate the functional changes that the IETF is making > > in its protocols to other standards organizations that > > are responsible for related (e.g., management) standards. > > That enables those organizations to make any changes that > > they deem appropriate based on their expertise - in contrast, > > issuing explicit instructions to another standards organization > > has the potential to go over badly (IMHO). The draft charter > > already contains references to working relationships with T10 > > and T11 - it looks like it needs corresponding text for SNIA > > around the iSCSI HBA API and SMI-S support for iSCSI. >=20 > I think you misunderstood my intentions. If non-IETF standards for > management=20 > (SNIA SMI-S and T10/T11 HBA) are widely used in the real world, and > IETF management > standards are not widely used to manage iSCSI, FCIP, etc., then we > should=20 > consider how **our** standards - iSCSI, FCIP, storage MIBs, etc., > should be > modified to work better with those widely-deployed non-IETF standards > for=20 > storage management. Or whether a combination of IETF management > standards (syslog, > netconf, and SNMP) would be more suitable than the SNMP-only approach. >=20 > If SCSI is usually managed using HBA and not SNMP, then we should > consider whether > **i**SCSI needs to be changed to allow consistent (both i* and non-i*) > SCSI management. > Maybe we need changes to iSCSI to make it compatible with SNMP and HBA > and SMI-S. >=20 > >=20 > > Not announcing the BoF on the IETF list was my oversight; > > that clearly should have been done prior to San Francisco. > > I'll work with Lars on ensuring that there is sufficiently > > broad IETF exposure and review of the proposed storm charter. >=20 > Thanks. >=20 > >=20 > > For the security concerns, please see RFC 3723 (Securing > > Block Storage Protocols over IP). I expect that RFC to > > remain applicable to all of the revised protocols, with the > > overall approach being that security issues in technology that > > is standardized by another standards body are the responsibility > > of that standards body; would a statement to that effect (RFC > > 3723 expected to remain applicable, security issues in standards > > from other organizations remain the responsibility of those > > organizations) in the charter be helpful? =20 >=20 > Having such a statement would have made it clearer to people like me > who are not in the other organizations. >=20 > >=20 > > That said, I am surprised by what appears to be an inference > > that lack of mention of security in the charter implies that > > security may not be addressed at all. All RFCs have to address > > security considerations, making security something that every > > IETF WG has to address, independent of whether security is > > explicitly mentioned in the WG charter. If every WG charter > > now has to have a "Security Considerations" section, there are > > number of WG charters on the IETF web site that need updates > > ... surely the IESG has better things to do ;-). >=20 > I did not overlook that you would need to deal with Security > Considerations. >=20 > I did overlook RFC3723. There are lots of documents related to iSCSI=20 > and iFC and FCIP and iSNS and ... I simply haven't had time to study > all of them. >=20 > The problem I have is that I could not look at the documents from > INCITS=20 > to determine the status of security for SCSI/iSCSI and FC/FCIP, etc.=20 > I suspect the INCITS documents do not directly discuss iSCSI security. > My=20 > impression is T10/T11 focus on non-Internet connectivity, where > security > concerns/threats might be different than for Internet connectivity. >=20 > INCITS did make public their intention to update SAM-4 to address > security. > Apparently they think there is something that needs addressing. > But I don't know what they know, because they don't say what needs=20 > addressing and you don't say anything about upgrading security as you > upgrade the i* variations of the underlying protocols. > (Maybe the SAM-4 pretty picture of the architecture needs to be > updated > to show the security boxes. But the SAM-5 proposal simply doesn't say > what=20 > needs to be done, so i cnanto see if it is something simple or > something difficult > that could impact making storage accessible securely over the > Internet.) >=20 > >=20 > > Regarding SAM-5, the draft storm WG charter references SAM-4 > > and not SAM-5 for a reason; SAM-5 is an out-of-scope moving > > target. =20 >=20 > Understood. I was not suggesting we should try for SAM-5 > compatibility. >=20 > > FWIW, most SCSI (T10) security is not in the SAM > > standards, but rather in the SPC-4 standard (under development). > > For Fibre Channel (T11) security, see the FC-SP standard and > > the FC-SP-2 standard (under development). > >=20 > > That brings me to the T10 and T11 standards access concerns, > > which are real and something I need to work on. INCITS, the > > parent organization of T10 and T11, imposed new document > > access restrictions within the past year. I need to work > > with T10 and T11 on how to go about making the necessary > > standards documents available to IETF participants, starting > > with T10 (which meets next week). I do not intend to ask > > the IESG for approval of the storm WG charter until the > > document access concerns are resolved. > >=20 > > Thanks, > > --David > > =20 > >=20 > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > > Sent: Thursday, April 30, 2009 12:30 PM > > > To: 'Lars Eggert'; 'Ersue, Mehmet (NSN - DE/Munich)' > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; Black, David;=20 > > > iesg@ietf.org; iesg@ietf.org; 'IAB' > > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > > Maintenance (storm) > > >=20 > > > Hi, > > >=20 > > > I found that having the discussion for the STORM BOF on the > mailing > > > lists for (three) concluded WGs made it a bit obscure. > > > As far as I can tell by looking at those archives, there wasn't > much > > > discussion. > > > I will also note that the announcement of the craetion of the > storm > > > list seems to be have been only announced to the lists of the > three > > > concluded WGs. So if you weren't involved in the three earlier > WGs, > > > you might not have seen the announcement.=20 > > >=20 > > > I do think Mehmet has a point that many IETF people may not=20 > > have been > > > aware the discussion was happening. > > >=20 > > > As an OPSDIR member and MIB Doctor, I have already=20 > > expressed concerns > > > that operations and management is not being addressed in=20 > > the charter. > > > The chair helpfully responded with a short list of management > > > standards (SNIA SMI-S, SNIA SCSI HBA, INCITS FC HBA) that might > help > > > answer my questions. Unfortunately, I cannot access some of the > > > documents referenced because they are not freely available.=20 > > If I read > > > through a number of large standards I might be able to determine > for > > > myself what changes might need to be made to utilize the existing > > > non-IETF standards to manage the updated IETF storage standards. I > > > think I would rather see the WG consdier this and document=20 > > it, rather > > > than me (and any other user of the IETF technologies) having to > > > research this personally to know the answers. I would nto say my > > > concerns have been addressed. > > >=20 > > > As a SECDIR member, I have concerns that security may not be > gettng > > > addressed either, but it is hard for me to say that for sure since > I > > > cannot freely access the T10 and T11 documents that are the basis > of > > > the updates. I do not know whether the updated IETF storage=20 > > standards > > > will utilize IETF standards for security or non-IETF stndards for > > > security, or whether the WG is simply not going to address > security > > > issues since it is not mentioned in the charter. I note that the > > > charter calls for updating to SAM-4 level, and that T10 is > starting > > > new work on SAM-5, explicitly to address security. So does that > mean > > > security will not be addressed in the STORM WG? > > >=20 > > > I have not seen these discussions elsewhere. And Mehmet's concerns > > > seem to be relevant to that point. > > >=20 > > > Before the WG is created, I think the charter should be=20 > > explicit about > > > the what the WG will do to address how these Internet=20 > > protocols should > > > be operated and managed and secured. > > > =20 > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > >=20 > > > > -----Original Message----- > > > > From: ops-dir-bounces@ietf.org=20 > > > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Lars Eggert > > > > Sent: Tuesday, April 28, 2009 12:44 PM > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org;=20 > > > > Black_David@emc.com; iesg@ietf.org > > > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage=20 > > > > Maintenance (storm) > > > >=20 > > > > Hi, > > > >=20 > > > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > > unfortunately I missed the Storm BoF in SF. I also was not > aware > > > of > > > > > the discussion on the maillists you mention. > > > > > > > > > > I made the experience that announcing a BoF maillist to IETF > and > > > > > forcing some discussion on this maillist with IETF member =20 > > > > > participation > > > > > is a good way to show IESG that there is measurable=20 > > IETF community > > > > > interest. > > > >=20 > > > > as David said below, there was discussion on the=20 > > > > still-existing RDDP, =20 > > > > IPS and IMSS lists, and the BOF went - in my opinion -=20 > > very well. I > > >=20 > > > > believe community interest has been demonstrated, which=20 > > is why we're > > >=20 > > > > going forward with a charter proposal. > > > >=20 > > > > > The huge amount of people in the session, which are sometimes > > > > > occasionally in the room and vote, usually disappear when=20 > > > > it comes to > > > > > maillist discussion. Also for our regular WG work the > decisions > > > have > > > > > to be confirmed on the maillist. > > > > > > > > > > As I said I believe this is an important and necessary > > > consolidation > > > > > work but should be discussed and accepted first in the IETF=20 > > > > community. > > > >=20 > > > > I don't quite know what to do with you comment. Are you=20 > > saying there > > >=20 > > > > hasn't been sufficient discussion to go forward with the=20 > > chartering? > > >=20 > > > > Or am I misunderstanding? > > > >=20 > > > > I'll also note that the community obviously still has time to=20 > > > > comment =20 > > > > - the charter is in internal I* review at this time,=20 > > after which it > > >=20 > > > > will go for public review. > > > >=20 > > > > Lars > > > >=20 > > > > > > > > > > Cheers, > > > > > Mehmet > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] > > > > >> Sent: Tuesday, April 28, 2009 2:32 PM > > > > >> To: Ersue, Mehmet (NSN - DE/Munich) > > > > >> Cc: dromasca@avaya.com; Black_David@emc.com > > > > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > > >> Maintenance (storm) > > > > >> > > > > >> Mehmet, > > > > >> > > > > >> The storm list is completely new (it was only opened for > people > > > > >> to subscribe within the past few days). The storm BOF in San > > > > >> Francisco was organized using the existing IPS, RDDP and IMSS > > > > >> mailing lists. I suggest consulting the archives for those > > > > >> lists, particularly for the IPS list, where you should find a > > > > >> reasonable level of community interest. > > > > >> > > > > >> There is definite community interest in this work, and I have > > > > >> author commitments for drafts for all six work items listed > > > > >> in the charter - each of the "First version of" milestone > > > > >> dates in the proposed charter is based on discussion with an > > > > >> author or authors who believe that a first version of the > draft > > > > >> will be ready by that date. > > > > >> > > > > >> Thanks, > > > > >> --David > > > > >> ---------------------------------------------------- > > > > >> David L. Black, Distinguished Engineer > > > > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > >> black_david@emc.com Mobile: +1 (978) 394-7754 > > > > >> ---------------------------------------------------- > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > >>> Sent: Tuesday, April 28, 2009 6:33 AM > > > > >>> To: Ersue, Mehmet (NSN - DE/Munich) > > > > >>> Cc: Black, David > > > > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > > >>> Maintenance (storm) > > > > >>> > > > > >>> Mehmet, > > > > >>> > > > > >>> David Black ran the BOF in San Francisco. He should be able > > > > >> to provide > > > > >>> you information about the preparation work, level of=20 > > support and > > > > >>> interest from the community and initial drafts. > > > > >>> > > > > >>> Thanks for looking into this and for asking the questions. > > > > >>> > > > > >>> Dan > > > > >>> > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Ersue, Mehmet (NSN - DE/Munich) > > > > >> [mailto:mehmet.ersue@nsn.com] > > > > >>>> Sent: Tuesday, April 28, 2009 1:29 PM > > > > >>>> To: Romascanu, Dan (Dan) > > > > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > > > >>>> Maintenance (storm) > > > > >>>> > > > > >>>> > > > > >>>> Hi Dan, > > > > >>>> > > > > >>>> I believe this is an important and necessary consolidation > > > work. > > > > >>>> > > > > >>>> I might have missed the discussion on another maillist but > > > > >>>> the storm maillist is pretty much new and I would have a > > > > >>>> better feeling if there were some mail traffic showing the > > > > >>>> interest of the community and/or an initial draft with an > > > > >>>> issues list for the justification of a new WG. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Mehmet > > > > >>>> > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: ops-dir-bounces@ietf.org > > > > >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext=20 > > Romascanu, > > > > >>>>> Dan (Dan) > > > > >>>>> Sent: Monday, April 27, 2009 7:57 PM > > > > >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org > > > > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage > > > > >>>> Maintenance (storm) > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: iesg-bounces@ietf.org=20 > > [mailto:iesg-bounces@ietf.org] On > > > > >>>>> Behalf Of > > > > >>>>> IESG Secretary > > > > >>>>> Sent: Monday, April 27, 2009 8:54 PM > > > > >>>>> To: iesg@ietf.org; iab@iab.org > > > > >>>>> Cc: black_david@emc.com > > > > >>>>> Subject: Internal WG Review: STORage Maintenance (storm) > > > > >>>>> > > > > >>>>> A new IETF working group is being considered in the=20 > > Transport > > > > >>>>> Area. The > > > > >>>>> draft charter for this working group is provided below for > > > > >>>> your review > > > > >>>>> and comment. > > > > >>>>> > > > > >>>>> Review time is one week. > > > > >>>>> > > > > >>>>> The IETF Secretariat > > > > >>>>> > > > > >>>>> STORage Maintenance (storm) > > > > >>>>> ---------------------------------- > > > > >>>>> > > > > >>>>> Last Modified: 2009-04-25 > > > > >>>>> > > > > >>>>> Current Status: Proposed Working Group > > > > >>>>> > > > > >>>>> Chairs: > > > > >>>>> - David L. Black > > > > >>>>> - tbd > > > > >>>>> > > > > >>>>> Transport Area Director(s): > > > > >>>>> - Magnus Westerlund > > > > >>>>> - Lars Eggert > > > > >>>>> > > > > >>>>> Transport Area Advisor: > > > > >>>>> - Lars Eggert > > > > >>>>> > > > > >>>>> Mailing Lists: > > > > >>>>> General Discussion: storm@ietf.org > > > > >>>>> To Subscribe: storm-request@ietf.org > > > > >>>>> In Body: (un)subscribe > > > > >>>>> Archive:=20 > > http://www.ietf.org/mail-archive/web/storm/index.html > > > > >>>>> > > > > >>>>> Description of Working Group: > > > > >>>>> > > > > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data > > > > >> Placement) > > > > >>>>> working groups have produced a significant number of > > > > >>>> storage protocols > > > > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is > significant > > > > >>>> usage. The > > > > >>>>> time has come to reflect feedback from implementation and > > > > >>> usage into > > > > >>>>> updated RFCs; this work may include: > > > > >>>>> > > > > >>>>> - Implementation-driven revisions and updates to existing > > > > >>> protocols > > > > >>>>> (i.e., updated RFCs that match the "running code"). > > > > >>>>> > > > > >>>>> - Interoperability reports as needed for the resulting > > > > >>>>> revised protocols > > > > >>>>> that are appropriate for Draft Standard RFC status. > > > > >>>>> > > > > >>>>> - Minor protocol changes or additions. Backwards > > > > >> compatibility is > > > > >>>>> required. > > > > >>>>> > > > > >>>>> Significant changes to the existing protocol standards are > > > > >>>>> out of scope, > > > > >>>>> including any work on version 2 of any of these protocols. > > > > >>>>> > > > > >>>>> Stability is critical to the usage of these protocols, so > > > > >>> backwards > > > > >>>>> compatibility with existing implementations will be a > > > > >> requirement > > > > >>>>> imposed on for all protocol changes and additions. Note > > > > >>>> that this is a > > > > >>>>> requirement for implementation compatibility - if it is > the > > > > >>>> case that > > > > >>>>> all implementations of a protocol have done something > > > > >>> different than > > > > >>>>> what the RFC specifies, it is appropriate for a new RFC to > > > > >>>>> document what > > > > >>>>> the "running code" actually does and deprecate the > > > > >> unused original > > > > >>>>> behavior. > > > > >>>>> > > > > >>>>> Initial list of work items: > > > > >>>>> > > > > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), > > > > >> 4850 (node > > > > >>>>> architecture key) and 5048 (corrections/clarifications) > > > > >>>> into one draft > > > > >>>>> (3720bis), removing features that are not implemented in > > > > >>>>> practice. This > > > > >>>>> draft should be prepared so that it could become a Draft > > > > >>>> Standard RFC, > > > > >>>>> but it is up to the to decide whether to advance it to > > > > >>>> Draft Standard. > > > > >>>>> > > > > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version > > > > >> of the SCSI > > > > >>>>> architecture) in a backwards-compatible fashion, as iSCSI > > > > >>>> is currently > > > > >>>>> based on SAM-2. This will be a separate draft from the > > > > >>>> iSCSI update in > > > > >>>>> the previous bullet. The Working group may add additional > > > > >>>> minor useful > > > > >>>>> iSCSI features to this draft. > > > > >>>>> > > > > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a > > > > >>> precursor of the > > > > >>>>> FCIP protocol in 2000, but this allocated number is not > > > > >>>> used by FCIP. > > > > >>>>> The working group will consider whether this=20 > > allocated number > > > > >>>>> should be > > > > >>>>> returned to IANA for future reallocation. > > > > >>>>> > > > > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be > > > > >>>> deprecated > > > > >>>>> (SHOULD NOT implement or use), as there are significant > > > > >> technical > > > > >>>>> problems with its specification, and moreover, only the > > > Address > > > > >>>>> Transparent mode of iFCP is in use. This will be done via > a > > > > >>>>> short draft > > > > >>>>> that updates RFC 4172, and not via a complete rewrite of > > > > >>> RFC 4172. A > > > > >>>>> combined draft is expected that encompasses items=20 > > (3) and (4). > > > > >>>>> > > > > >>>>> (5) RDDP MPA: Good support for MPI applications requires a > > > > >>>>> small update > > > > >>>>> to the startup functionality to allow either end of the > > > > >>>> connection to > > > > >>>>> initiate. > > > > >>>>> > > > > >>>>> (6) iSER: Experience with Infiniband implementations > suggest > > > > >>>>> a few minor > > > > >>>>> updates to reflect what has been done in practice. > > > > >>>>> > > > > >>>>> The working group is expected to maintain good working > > > > >>> relationships > > > > >>>>> with INCITS Technical Committee T10 (SCSI standards) and > > > INCITS > > > > >>>>> Technical Committee T11 (Fibre Channel standards) via > > > > >> overlaps in > > > > >>>>> membership as opposed to appointment of formal liaisons. > > > > >>> The liaison > > > > >>>>> process (including IAB appointment of a liaison or > > > > >>>>> liaisons) remains available for use if needed. > > > > >>>>> > > > > >>>>> Goals and Milestones: > > > > >>>>> > > > > >>>>> June 2009 First version of FCIP protocol number and iFCP > > > Address > > > > >>>>> Translation mode draft > > > > >>>>> > > > > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new > > > > >>>> features draft. > > > > >>>>> > > > > >>>>> Aug 2009 First version of RDDP MPA startup change draft > > > > >>>>> > > > > >>>>> Sep 2009 Working Group Last Call on FCIP protocol > > > > >> number and iFCP > > > > >>>>> address change draft > > > > >>>>> > > > > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) > > > > >>>>> > > > > >>>>> Oct 2009 First version of iSER update draft > > > > >>>>> > > > > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup > > > > >> change draft. > > > > >>>>> > > > > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) > > > > >>> new features > > > > >>>>> draft. > > > > >>>>> > > > > >>>>> Feb 2010 Working Group Last Call on iSER update draft > > > > >>>>> > > > > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and > > > > >> other) new > > > > >>>>> features draft. > > > > >>>>> > > > > >>>>> April 2010 Working Group decision on whether to seek Draft > > > > >>>>> Standard RFC > > > > >>>>> status for the combined iSCSI draft (3720bis). [Note: > > > > >>>>> decision may be made significantly before this date.] > > > > >>>>> > > > > >>>>> Sep 2010 Working Group Last Call on combined iSCSI > > > > >> draft (3720bis) > > > > >>>>> _______________________________________________ > > > > >>>>> OPS-DIR mailing list > > > > >>>>> OPS-DIR@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir > > > > >>>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > >=20 > > > > _______________________________________________ > > > > OPS-DIR mailing list > > > > OPS-DIR@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ops-dir > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 From Black_David@emc.com Fri May 1 14:41:33 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB5B3A6A75; Fri, 1 May 2009 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9D9b9aaIz8UY; Fri, 1 May 2009 14:41:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id A89CE3A69A8; Fri, 1 May 2009 14:41:26 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n41Lgjfs004573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 17:42:45 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 1 May 2009 17:42:37 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n41LgaIh022661; Fri, 1 May 2009 17:42:37 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 17:42:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 17:41:58 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB675@CORPUSMX80A.corp.emc.com> In-Reply-To: <049801c9ca93$c67e50a0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwAAJw83YAABI6TAAAHgsDAAAIw6EAADjTbAAAGDgJA= References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> <049801c9ca93$c67e50a0$0600a8c0@china.huawei.com> To: , , , X-OriginalArrivalTime: 01 May 2009 21:42:36.0660 (UTC) FILETIME=[BE392340:01C9CAA5] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:41:33 -0000 David H, > > I agree with almost everything you wrote (and I have a track > > record of addressing issues from other areas in WGs that I've > > run). OTOH, I have a concern here in that the M in STORM > > stands for "Maintenance" - there are a bunch of moderately > > sized updates and cleanup that need to be done to the protocol > > specs in this area. Rightly or wrongly, I perceive the direction > > of Dave H's questions as wanting to explore completely reworking > > storage-related management. > >=20 >=20 > Actually, I think that is partially right and partially wrong. > I do not know how large the differences are between the SAM-2 > architectural model and the SAM-4 architectural model, but I > assume there are some significant differences that will be done > as part of the STORM "maintenance".=20 I don't believe that's a good assumption. This material was discussed in the San Francisco STORM BOF and is in the proceedings: http://www.ietf.org/proceedings/09mar/slides/storm-3.pdf Most of the items listed there are relatively small in scope. [... remainder snipped ...] Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From dromasca@avaya.com Sun May 3 08:46:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A863A6F1D; Sun, 3 May 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] 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 zXy0piiVi43y; Sun, 3 May 2009 08:46:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 222253A70E1; Sun, 3 May 2009 08:46:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144738660" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 11:47:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 11:47:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 17:44:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt to Informational RFC Thread-Index: AcnIz22AOC9SfRXdScyLjJ3/8ipFPwDNnp5w From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 15:46:27 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-approach es-06.txt=20 Technical Summary RSVP signaling can be used to make end-to-end resource=20 reservations in an IP network in order to guarantee the=20 QoS required by certain flows. With conventional RSVP,=20 both the data sender and receiver of a given flow take=20 part in RSVP signaling. Yet, there are many use cases=20 where resource reservation is required, but the=20 receiver, the sender, or both, is not RSVP-capable. =20 Where the receiver is not RSVP-capable, an RSVP router=20 may behave as an RSVP Receiver Proxy thereby performing=20 RSVP signaling on behalf of the receiver. This allows=20 resource reservations to be established on the segment=20 of the end-to-end path from the sender to the RSVP=20 Receiver Proxy. =20 The Proto document defines the RSVP extensions that are=20 needed to facilitate operations with an RSVP Receiver=20 Proxy whose signaling is triggered by receipt of RSVP=20 Path messages from the sender. =20 Working Group Summary The consensus for the publication was strong but from a=20 small group within the WG. Document Quality The shepherd doesn't know of any implementations. The=20 documents could have benefited from wider review. Personnel WG Shepherd and responsible AD is Magnus Westerlund. Note to RFC Editor =20 (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) From dromasca@avaya.com Sun May 3 08:46:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E28E3A6A12; Sun, 3 May 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_OBFU_TECHNOLOGIES=1.604, SARE_SUB_OBFU_Q1=0.227] 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 iuov7U5vwcWP; Sun, 3 May 2009 08:46:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1F8443A70DF; Sun, 3 May 2009 08:46:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144738659" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 11:47:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 11:47:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 17:47:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-roll-indus-routing-reqs-05.txt toInformational RFC Thread-Index: AcnI4xu88rqn9S7vQ+W9S+S0xoaF6QDILdaA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-roll-indus-routing-reqs-05.txt toInformational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 15:46:27 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-0 4.txt Technical Summary Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers by extending the information set available from wired systems. In an industrial environment, low power, high reliability, and easy installation and maintenance are mandatory qualities for wireless devices. The aim of this document is to analyze the requirements for the routing protocol used for Low power and Lossy Networks (LLN) in industrial environments. IPv6 is perceived as a key technology to provide the scalability and interoperability that are required in that space and is being more and more present in standards and products under development and early deployments. Cable is perceived as a more proven, safer techhnology, and existing, operational deployments are very stable in time. For these reasons, it is not expected that wireless will replace wire in any foreseeable future; the consensus in the industrial space is rather that wireless will tremendously augment the scope and benefits of automation by enabling the control of devices that were not connected in the past for reasons of cost and/or deployment complexities. But for LLN to be adopted in the industrial environment, the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The routing protocol used for low power and lossy networks (LLN) is important to fulfilling these goals. Industrial automation is segmented into two distinct application spaces, known as "process" or "process control" and "discrete manufacturing" or "factory automation". In industrial process control, the product is typically a fluid (oil, gas, chemicals ...). In factory automation or discrete manufacturing, the products are individual elements (screws, cars, dolls). While there is some overlap of products and systems between these two segments, they are surprisingly separate communities. The specifications targeting industrial process control tend to have more tolerance for network latency than what is needed for factory automation. Irrespective of this different 'process' and 'discrete' plant nature both plant types will have similar needs for automating the collection of data that used to be collected manually, or was not collected before. Examples are wireless sensors that report the state of a fuse, report the state of a luminary, HVAC status, report vibration levels on pumps, report man-down, and so on. Other novel application arenas that equally apply to both 'process' and 'discrete' involve mobile sensors that roam in and out of plants, such as active sensor tags on containers or vehicles. Some if not all of these applications will need to be served by the same low power and lossy wireless network technology. This may mean several disconnected, autonomous LLN networks connecting to multiple hosts, but sharing the same ether. Interconnecting such networks, if only to supervise channel and priority allocations, or to fully synchronize, or to share path capacity within a set of physical network components may be desired, or may not be desired for practical reasons, such as e.g. cyber security concerns in relation to plant safety and integrity. All application spaces desire battery operated networks of hundreds of sensors and actuators communicating with LLN access points. In an oil refinery, the total number of devices might exceed one million, but the devices will be clustered into smaller networks that in most cases interconnect and report to an existing plant network infrastructure. Working Group Summary No controversy. Document Quality The I-D is informational and specifies IPv6 routing requirements. =20 Personnel Who is the Document Shepherd for this document? JP Vasseur (jvasseur@cisco.com) Who is the Responsible Area Director? Adrian Farrel (adrian.farrel@huawei.com) RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Sun May 3 08:46:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1FF3A6F52; Sun, 3 May 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] 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 99+at64Pcnu0; Sun, 3 May 2009 08:46:26 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2B2883A70E2; Sun, 3 May 2009 08:46:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144738661" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 11:47:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 11:47:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 17:44:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-tsvwg-rsvp-proxy-proto-08.txt to Proposed Standard Thread-Index: AcnIz2NWeZrN3qgqT+SzG7SuiT/gjADNqJeg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-tsvwg-rsvp-proxy-proto-08.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 15:46:27 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-08 .txt Technical Summary RSVP signaling can be used to make end-to-end resource=20 reservations in an IP network in order to guarantee the=20 QoS required by certain flows. With conventional RSVP,=20 both the data sender and receiver of a given flow take=20 part in RSVP signaling. Yet, there are many use cases=20 where resource reservation is required, but the=20 receiver, the sender, or both, is not RSVP-capable. =20 Where the receiver is not RSVP-capable, an RSVP router=20 may behave as an RSVP Receiver Proxy thereby performing=20 RSVP signaling on behalf of the receiver. This allows=20 resource reservations to be established on the segment=20 of the end-to-end path from the sender to the RSVP=20 Receiver Proxy. =20 The Proto document defines the RSVP extensions that are=20 needed to facilitate operations with an RSVP Receiver=20 Proxy whose signaling is triggered by receipt of RSVP=20 Path messages from the sender. =20 Working Group Summary The consensus for the publication was strong but from a=20 small group within the WG. Document Quality The shepherd doesn't know of any implementations. The=20 documents could have benefited from wider review. Personnel WG Shepherd and responsible AD is Magnus Westerlund. Note to RFC Editor =20 (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) From dromasca@avaya.com Sun May 3 08:46:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF093A68F5; Sun, 3 May 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 DC1xQChyDthz; Sun, 3 May 2009 08:46:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 33C653A6F55; Sun, 3 May 2009 08:46:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144738662" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 11:47:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 11:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 17:46:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-templin-isatapv4-02.txt to Informational RFC Thread-Index: AcnIve86pGUoCoiRTkO206F8rg53xADSFuKg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-templin-isatapv4-02.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 15:46:28 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-isatapv4-02.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This is an update to RFC 5214 to support IPv4 unicast and multicast over IPv4, similar to IPv6 over IPv4 already supported. Working Group Summary This is an independent submission and nothing to do with the IETF or its WGs. Document Quality Unverified. Personnel Jari Arkko is the responsible AD for performing the RFC 3932 check. RFC Editor Note Response 2 from RFC 3932 Section 3 applies: 2. The IESG thinks that this work is related to IETF work done in IETF WGs such as V6OPS, BEHAVE, and SOFTWIRE but this does not prevent publishing. This approval is conditional on the acceptance of the following edit, in order to avoid redefining RFC 3330 address block for a new use: OLD: L3ADDR is taken from a global-scoped IPv4 prefix (e.g., 192.0.2/24). NEW: L3ADDR is taken from a global-scoped IPv4 prefix. IRTF Note (Insert IRTF Note here or remove section) IESG Note The following IESG note should be added to the document (RFC 3932 note number 2 from Section 4): This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Sun May 3 09:19:41 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762BA28C259; Sun, 3 May 2009 09:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] 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 k3UPOcyfBvpI; Sun, 3 May 2009 09:19:40 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C867728C274; Sun, 3 May 2009 09:19:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144739450" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 12:21:03 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 12:21:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 18:20:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Open Authentication Protocol (oauth) Thread-Index: AcnILGcSDN8gCCJKSza09jx/FI/kXQD3qMUg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Open Authentication Protocol (oauth) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 16:19:41 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 28, 2009 9:07 PM To: new-work@ietf.org Subject: WG Review: Open Authentication Protocol (oauth)=20 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 5, 2009. Open Authentication Protocol (oauth) ------------------------------------- Last Modified: 2009-04-06 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources ontheir behalf. * A mechanism for signing HTTP requests with the token- secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg"=20 scenerio). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard From mehmet.ersue@nsn.com Sun May 3 12:47:09 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D3E3A6F75; Sun, 3 May 2009 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599] 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 YkGOZ-x3v2ew; Sun, 3 May 2009 12:47:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 40D7128C1D5; Sun, 3 May 2009 12:46:05 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n43JlRdh032560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 May 2009 21:47:27 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n43JlRjs013028; Sun, 3 May 2009 21:47:27 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 21:47:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 21:47:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt toProposed Standard thread-index: AcnHFqLCVujhgKtmRBaqBathBFTbowABE7bwAUL6wGA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 03 May 2009 19:47:26.0380 (UTC) FILETIME=[FC3396C0:01C9CC27] Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, netconf@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt toProposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 19:47:10 -0000 Hi Dan, I reviewed the document draft-thomson-beep-async-02.txt in general and for its operational impact. Summary:=20 The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. Review summary: The draft is an extension feature to the BEEP (Blocks Extensible Exchange Protocol) protocol. BEEP provides already asnychrony based on pipelining (intra-channel) and parallelism (inter-channel). This documents provides a feature as an extension to BEEP, that enables the creation of an asynchronous channel, which is not limited to pipelining. I.e. a serving peer can process requests and respond in any order. The document aims to become a proposed standard RFC but there is no discussion on why an asynchronous channel is really needed additional to the already existing asynchrony mechanisms in the original BEEP protocol, IOW why are the existing mechanisms are not sufficient. The documents claims the necessity but there are also no examples of applications which would need the described mechanism. =20 Although the document introduces additional state information which needs to be stored and managed it does not discuss scalability sufficiently. The document also does not introduce a configurable parameter for the 'maximum count of allowed parallel asynchronous channels'.=20 Also the document misses to disscuss what happens when a response does not follow a request, i.e. is missing the exception handling thereafter. Configurability in general has not been discussed in the document.=20 Performance considerations have not been discussed in the document.=20 The reviewer couldn't find the mail archive at the URL given in the concluded BEEP WG charter page. The current maillist seems to be linked on www.beepcore.org and the "asynchronous BEEP" thread is under: http://groups.google.com/group/beepwg/browse_thread/thread/db0255c634c7e b0c/982e385e39fef215?lnk=3Dgst&q=3D+Asynchronous+BEEP#982e385e39fef215 The document shepherding info states that are a few seconders on the maillist. The reviewer of the document found a lot of mails questioning the sense of such an extension to the BEEP protocol (see URL above, e.g. "Anyways, reading through the draft, I think one reason I am resistant to this feature is that I do not fully understand when it would better than the alternatives."). Review Questions: Is the document readable? Yes. Does it contain nits? Yes (see below).=20 Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to = have RFC 2119 boilerplate text. =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 Is the document class appropriate? No. I would have nothing against such an extension if it would be Informational. I do not think this is a really necessary and long-awaited standard feature. Is the problem well stated? The mechanism has been described to some extent but exception handling and scalability discussion is not sufficient. Is the problem really a problem? The reviewer is not sure whether this feature is really needed as a standard. The necessity of the feature has been also questioned on the maillist. Does the document consider existing solutions? Obviously, there are a few products using BEEP (http://www.beepcore.org/products.html). The reviewer would like to see some use cases asking for the mechanism and requirements from BEEP users. Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Configuration parameters are not discussed in the document. Additional parameters supporting scalability would be interesting to have. Can performance be measured? How? Performance considerations have not been discussed in the document.=20 Does the solution scale well? A configurable parameter for the 'maximum count of allowed parallel asynchronous channels' would support scalability.=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Monday, April 27, 2009 11:32 AM > To: aaa-doctors@ietf.org; ops-dir@ietf.org; netconf@ietf.org > Subject: [OPS-DIR] FW: Evaluation:=20 > draft-thomson-beep-async-02.txt toProposed Standard >=20 >=20 > =20 >=20 >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-thomson-beep-async-0 > 2.txt-02.t > xt >=20 > Technical Summary >=20 > The Blocks Extensible Exchange Protocol (BEEP) provides a protocol > framework for the development of application protocols. This > document describes a BEEP feature that enables asynchrony for > individual channels. >=20 > Working Group Summary >=20 > This is an individual submission. >=20 > Document Quality >=20 > This was reviewed on the mailing list for the concluded BEEP WG. > There was moderate controversy about whether this extension was > needed as it is possible to work-around the lack of this feature > in BEEP at the next layer up. No other technical objections were > raised and there was explicit support from several parties. > At least one open source BEEP library implementation has agreed > to implement this extension. >=20 > Personnel >=20 > Chris Newman is the document shepherd. This has been reviewed for > the >=20 >=20 > IESG by Alexey Melnikov. Marshall Rose and other=20 > participants of the > BEEP WG mailing list reviewed this proposal. >=20 > RFC Editor Note >=20 > (Insert RFC Editor Note here or remove section) >=20 > IANA Note >=20 > (Insert IANA Note here or remove section) >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 From lars.eggert@nokia.com Mon May 4 00:01:51 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C696A3A6B7D; Mon, 4 May 2009 00:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 S10QZ5ct8QiN; Mon, 4 May 2009 00:01:51 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 035843A68C8; Mon, 4 May 2009 00:01:49 -0700 (PDT) Received: from [10.180.41.11] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n44732Ik029652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 10:03:02 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <5A5F66C7-E3E3-4F7E-A539-19FBF6C330A7@nokia.com> From: Lars Eggert To: Black_David@emc.com In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028EB675@CORPUSMX80A.corp.emc.com> Content-Type: multipart/signed; boundary=Apple-Mail-13--1027111591; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 10:02:56 +0300 References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com><03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com><047a01c9ca73$b3a67450$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB470@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A028EB508@CORPUSMX80A.corp.emc.com> <049801c9ca93$c67e50a0$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028EB675@CORPUSMX80A.corp.emc.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 04 May 2009 10:03:04 +0300 (EEST) Cc: "ops-dir@ietf.org" , "iab@ietf.org" , "aaa-doctors@ietf.org" , "mehmet.ersue@nsn.com" , "iesg@ietf.org" , "ietfdbh@comcast.net" Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:01:51 -0000 --Apple-Mail-13--1027111591 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, catching up on email after the long holiday weekend. I agree with David Black that omitting to include a focused work item on updating the relevant storage MIBs in conjunction with updating the storage protocols was an oversight that we should correct in the next version of the STORM charter. None of the current work items struck me as having an obvious impact on manageability, which probably explains why this is so, and we should add a task to STORM that ensures that all maintenance changes are compatible with the current MIBs or where that isn't possible slightly update them. I'm very hesitant to include any more fundamental work on operations and management of our suite of storage protocols in the STORM charter, because as David has pointed out, the goal is "maintenance" rather than "next major version". *If* the OPS community believes that major work is needed on the management aspects of IP storage, maybe it's time to bring back IMSS in some form? Lars --Apple-Mail-13--1027111591 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MDQwNzAyNTdaMCMGCSqGSIb3DQEJBDEWBBRpTCnWtHB14Xz3 pfH6OLtXF+9hSjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAHKBC02RQIT2zm10hnZa5sdbIote5WvW83ydJ3g3pvJpRLG2TvXGB OEuYmh+jbsGc8b44uCgkLXKb1lvkewMqbgSfZgZ3Fae6A98alTsqgOJiFFdnTflggPNJaqyrfsjf 6uLIZrAW9Q080bdEnJh/HkBBT0cDpj2/2L6pQWEeUAO5eiQSSIBOby+QYv08+jc18edrsQQfB3yd Ok3JyMhDjK+LKEynGyiAImyGeWZs253wJ1Wjv+BSFz0p1Gyy81qLKHSm6YHGt266oOU3Ve7Lvbw0 VUlBB+KHpkWEqeVCGAVnoxzpMNRltQHw5J1XmToqyjOWGuQVkYZ86jNIzQU+hQAAAAAAAA== --Apple-Mail-13--1027111591-- From mehmet.ersue@nsn.com Wed May 6 10:23:48 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B161A28C2EA; Wed, 6 May 2009 10:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599] 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 j1HTTnx4o0Kk; Wed, 6 May 2009 10:23:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 381EB3A70A3; Wed, 6 May 2009 10:17:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46HItO7032001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 19:18:55 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n46HIt1X015918; Wed, 6 May 2009 19:18:55 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 19:18:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 19:18:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard thread-index: AcnHFqLCVujhgKtmRBaqBathBFTbowABE7bwAUL6wGAAIEBf0AAZA+tAABPbPHA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Thomson, Martin" X-OriginalArrivalTime: 06 May 2009 17:18:55.0777 (UTC) FILETIME=[BC4EB910:01C9CE6E] Cc: ops-dir@ietf.org, aaa-doctors@ietf.org, draft-thomson-beep-async@tools.ietf.org, iesg@ietf.org, alexey.melnikov@isode.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:23:48 -0000 Dear Martin, > Sent: Tuesday, May 05, 2009 1:50 AM > To: Romascanu, Dan (Dan) > Cc: Alexey Melnikov; Ersue, Mehmet (NSN - DE/Munich) > Subject: RE: [OPS-DIR] FW: Evaluation:=20 > draft-thomson-beep-async-02.txt toProposed Standard >=20 > Thanks for forwarding this on Dan. >=20 > I'll deal with the smaller comments below, but there are two=20 > concerns that I'd like to address up front. >=20 > =3D=3DUse Case >=20 > The draft is quite clear on the use case - large volumes of=20 > requests that take a significant amount of time. I don't=20 > think that the draft could be any clearer without numbers. >=20 > If numbers are necessary for justification, imagine 1000=20 > requests per second with a 50+ second processing time. We've=20 > looked at the same problem for HTTP and it starts pushing the=20 > limits of what a single machine can handle. Even if the=20 > machine could handle the actual processing load, 50,000=20 > connections stresses most TCP stacks. >=20 > A single BEEP connection might handle this, but no BEEP stack=20 > is required to support 50,000 channels (the limit is 257),=20 > which is what would be required. Mehmet asserts that BEEP=20 > concurrency is adequate, but this is demonstrably not true in=20 > this case. I don't claim that this functionality is not useful. What I mean=20 is that the existing features might be already sufficient to solve=20 the same problem space and a new feature might not be necessary=20 as an "additional mandatory standard".=20 I would like to have the explanation and reasoning why this is a=20 required feature and why the existing features are not able to solve=20 the problem "as text in the document", IOW text proving that it is=20 a necessity and not nice to have. I don't have anything against this feature if it gets published as an Informational RFC.=20 However, the document is meant to become a BEEP-bis standard and I don't agree to publish it as a mandatory standard, without=20 the decision of a WG to extend an existing standard, without the=20 thorough discussion and development of a WG and without the=20 consensus reached in an IETF WG maillist, which is IMO absolutely=20 necessary if we want to extend an existing "IETF standard" with=20 an additional "mandatory standard feature". Threads in the BEEP maillist show that some of the implementers=20 of the BEEP standard think this feature is not needed. At least I saw=20 long mails from Sam Roberts and David Kramer, which you obviously=20 couldn't convince for the importance of your draft. PS: AFAIU there have been 4 persons commenting on your draft on=20 the BEEP maillist on www.beepcore.org (except Rainer Gerhards=20 who had a different concern). 50% of them were in favor and 50% against. I definitely don't see the necessary consensus in this maillist for=20 the publication of an BEEP-bis standard.=20 > =3D=3DConfigurability >=20 > Mehmet requests that the document define (?) a configuration=20 > parameter to limit the accumulation of state on the client=20 > peer. While this is not explicit in the document, I don't=20 > believe that it is necessary to be any more explicit than the=20 > security section is: >=20 > ...; the number of outstanding requests can be > restricted to protect against excessive accumulation of state. >=20 > Because this aspect is internal to the client peer, BEEP=20 > stacks are able to address this how they choose. I believe the short text on "state information" in the security=20 considerations section is insufficient for the necessary scalability=20 discussion in a standard-track document because of the reasons=20 I indicated. See more below . . . Mehmet > More inline below... >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, 4 May 2009 9:11 PM > > To: Thomson, Martin > > Cc: Alexey Melnikov; Ersue, Mehmet (NSN - DE/Munich) > > Subject: FW: [OPS-DIR] FW: Evaluation:=20 > draft-thomson-beep-async-02.txt > > toProposed Standard > >=20 > > Martin, > >=20 > > Please find below the OPS-DIR review of draft-thomson-beep-async- > > 02.txt. > >=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > > -----Original Message----- > > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > > Sent: Sunday, May 03, 2009 10:47 PM > > To: Romascanu, Dan (Dan) > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; netconf@ietf.org > > Subject: RE: [OPS-DIR] FW: Evaluation:=20 > draft-thomson-beep-async-02.txt > > toProposed Standard > >=20 > >=20 > > Hi Dan, > >=20 > > I reviewed the document draft-thomson-beep-async-02.txt in=20 > general and > > for its operational impact. > >=20 > > Summary: > > The Blocks Extensible Exchange Protocol (BEEP) provides a protocol > > framework for the development of application protocols. =20 > This document > > describes an BEEP feature that enables asynchrony for individual > > channels. > >=20 > >=20 > > Review summary: > >=20 > > The draft is an extension feature to the BEEP (Blocks Extensible > > Exchange Protocol) protocol. > > BEEP provides already asnychrony based on pipelining (intra-channel) > > and > > parallelism (inter-channel). This documents provides a feature as an > > extension to BEEP, that enables the creation of an asynchronous > > channel, > > which is not limited to pipelining. I.e. a serving peer can process > > requests and respond in any order. > >=20 > > The document aims to become a proposed standard RFC but there is no > > discussion on why an asynchronous channel is really needed=20 > additional > > to > > the already existing asynchrony mechanisms in the original BEEP > > protocol, IOW why are the existing mechanisms are not=20 > sufficient. The > > documents claims the necessity but there are also no examples of > > applications which would need the described mechanism. > >=20 > > Although the document introduces additional state information which > > needs to be stored and managed it does not discuss scalability > > sufficiently. The document also does not introduce a configurable > > parameter for the 'maximum count of allowed parallel asynchronous > > channels'. > > Also the document misses to disscuss what happens when a=20 > response does > > not follow a request, i.e. is missing the exception handling > > thereafter. > >=20 > > Configurability in general has not been discussed in the document. > > Performance considerations have not been discussed in the document. > >=20 > > The reviewer couldn't find the mail archive at the URL given in the > > concluded BEEP WG charter page. The current maillist seems=20 > to be linked > > on www.beepcore.org and the "asynchronous BEEP" thread is under: > >=20 > http://groups.google.com/group/beepwg/browse_thread/thread/db0 > 255c634c7 > > e > > = b0c/982e385e39fef215?lnk=3Dgst&q=3D+Asynchronous+BEEP#982e385e39fef215 > >=20 > > The document shepherding info states that are a few seconders on the > > maillist. The reviewer of the document found a lot of mails=20 > questioning > > the sense of such an extension to the BEEP protocol (see URL above, > > e.g. > > "Anyways, reading through the draft, I think one reason I=20 > am resistant > > to this feature is that I do not fully understand when it=20 > would better > > than the alternatives."). >=20 > These concerns were expressed by one or two on the mailing=20 > list. The use case was not the problem, only the manner in=20 > which it was solved. >=20 > The objectors held that the problem should be solved by the=20 > application protocol, not BEEP. By adding an identifier to=20 > application-layer messages, requests and responses could be=20 > sent in MSG frames. =20 >=20 > Aside from doubling the number of messages, this places a=20 > burden on the application protocol. Consider RFC 4227=20 > (BEEP+SOAP) and whether it would be appropriate to modify the=20 > payload to support a particular protocol binding. >=20 > > Review Questions: > >=20 > > Is the document readable? > >=20 > > Yes. > >=20 > > Does it contain nits? > >=20 > > Yes (see below). > >=20 > > Miscellaneous warnings: > >=20 > >=20 > -------------------------------------------------------------- > --------- > > - > > ---- > >=20 > > =3D=3D The document doesn't use any RFC 2119 keywords, yet=20 > seems to have > > RFC > > 2119 boilerplate text. >=20 > This is consistent with the source material (RFC 3080). It's=20 > a small thing, but I see no strong reason to make a change. I don't agree. Standard documents should use the RFC 2119=20 KEYWORDS in a specific way and should highlight the=20 KEYWORDS for clarity. > > =3D=3D The document seems to lack a disclaimer for=20 > pre-RFC5378 work, but > > was > > first submitted before 10 November 2008. Should you add the > > disclaimer? > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.). >=20 > The disclaimer is not necessary. I am able to answer for all=20 > of the contributors. I'm not really sure whether the disclaimer is not necessary. The=20 BEEP standard is used as a basic input for the document. Actually=20 this is going to be a BEEP-bis document. > > Is the document class appropriate? > >=20 > > No. I would have nothing against such an extension if=20 > it would be > > Informational. I do not think this is a really necessary and > > long-awaited standard feature. >=20 > The comments above should address this and the consequent concerns. > =20 > > Is the problem well stated? > >=20 > > The mechanism has been described to some extent but exception > > handling and scalability discussion is not sufficient. > >=20 > > Is the problem really a problem? > >=20 > > The reviewer is not sure whether this feature is=20 > really needed as > > a standard. The necessity of the feature has been also questioned on > > the > > maillist. > >=20 > > Does the document consider existing solutions? > >=20 > > Obviously, there are a few products using BEEP > > (http://www.beepcore.org/products.html). The reviewer would=20 > like to see > > some use cases asking for the mechanism and requirements from BEEP > > users. > >=20 > > Does the solution break existing technology? > >=20 > > No. > >=20 > > Does the solution preclude future activity? > >=20 > > No. > >=20 > > Is the solution sufficiently configurable? > >=20 > > Configuration parameters are not discussed in the document. > > Additional parameters supporting scalability would be=20 > interesting > > to > > have. > > > > Can performance be measured? How? > >=20 > > Performance considerations have not been discussed in=20 > the document. > >=20 > > Does the solution scale well? > >=20 > > A configurable parameter for the 'maximum count of=20 > allowed parallel > > asynchronous channels' would support scalability. > >=20 > > Cheers, > > Mehmet > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 From alexey.melnikov@isode.com Wed May 6 10:59:57 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA773A7020; Wed, 6 May 2009 10:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 tlOWLt5+pBr4; Wed, 6 May 2009 10:59:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A943E3A7077; Wed, 6 May 2009 10:54:22 -0700 (PDT) Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 18:55:48 +0100 Message-ID: <4A01CF05.1010100@isode.com> Date: Wed, 06 May 2009 18:55:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Ersue, Mehmet (NSN - DE/Munich)" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 May 2009 11:00:38 -0700 Cc: ops-dir@ietf.org, aaa-doctors@ietf.org, draft-thomson-beep-async@tools.ietf.org, iesg@ietf.org, "ext Thomson, Martin" Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:59:57 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: >Dear Martin, > > Dear Mehmet, >>Sent: Tuesday, May 05, 2009 1:50 AM >>To: Romascanu, Dan (Dan) >>Cc: Alexey Melnikov; Ersue, Mehmet (NSN - DE/Munich) >>Subject: RE: [OPS-DIR] FW: Evaluation: >>draft-thomson-beep-async-02.txt toProposed Standard >> >>Thanks for forwarding this on Dan. >> >>I'll deal with the smaller comments below, but there are two >>concerns that I'd like to address up front. >> >>==Use Case >> >>The draft is quite clear on the use case - large volumes of >>requests that take a significant amount of time. I don't >>think that the draft could be any clearer without numbers. >> >>If numbers are necessary for justification, imagine 1000 >>requests per second with a 50+ second processing time. We've >>looked at the same problem for HTTP and it starts pushing the >>limits of what a single machine can handle. Even if the >>machine could handle the actual processing load, 50,000 >>connections stresses most TCP stacks. >> >>A single BEEP connection might handle this, but no BEEP stack >>is required to support 50,000 channels (the limit is 257), >>which is what would be required. Mehmet asserts that BEEP >>concurrency is adequate, but this is demonstrably not true in >>this case. >> >> >I don't claim that this functionality is not useful. What I mean >is that the existing features might be already sufficient to solve >the same problem space and a new feature might not be necessary >as an "additional mandatory standard". > >I would like to have the explanation and reasoning why this is a >required feature and why the existing features are not able to solve >the problem "as text in the document", IOW text proving that it is >a necessity and not nice to have. > > Noted. I will add an RFC Editor note for this, or the author will revise the document to add such text. >I don't have anything against this feature if it gets published as an >Informational RFC. > >However, the document is meant to become a BEEP-bis standard >and I don't agree to publish it as a mandatory standard, > This feature is not mandatory - it is negotiated by the client. So I don't understand why you keep calling this BEEP-bis and "mandatory standard". >without >the decision of a WG to extend an existing standard, without the >thorough discussion and development of a WG and without the >consensus reached in an IETF WG maillist, which is IMO absolutely >necessary if we want to extend an existing "IETF standard" with >an additional "mandatory standard feature". > > [snip] -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From lisa.dusseault@gmail.com Wed May 6 12:04:37 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735923A6F62; Wed, 6 May 2009 12:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 P+NKfEw273sb; Wed, 6 May 2009 12:04:29 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 2A62F3A70BF; Wed, 6 May 2009 11:55:16 -0700 (PDT) Received: by ewy24 with SMTP id 24so455125ewy.37 for ; Wed, 06 May 2009 11:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n/OalQuTGdn0mjF+5kxW/KMbRS772BHmRVnRlPRj/oo=; b=lLQjsP8b3AqXA2otsGqrZo+mP4bxLE2SuFdM8rJI5DeTkQBOU8ykmPlZ1VxlIhKm4q ttMoJiu1fYdNi/LOFcay3WdXdxgBvUfjrX/t0F11+D0hM60A7bmI0imm2peEJpoAwid8 tAmukunKXWFg790o1ARBUIJdBdThHlcPfMY5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jq6HXSgtpS6hgnAwen/zRFi2mDeJrvHAltLdbLROmnPluF6ef6155ccWpJKIRvuDVW CyYAw6tNq4f3dFTiFKBCJ8cVSA2clDUP1MccOgeYeR/4zTuiV0fFxyWNjMGrFLscc14X 8bfF5yamlcmGBB1e19QSgNAeTUd8N/9QBDQhI= MIME-Version: 1.0 Received: by 10.220.44.194 with SMTP id b2mr3323774vcf.83.1241636197387; Wed, 06 May 2009 11:56:37 -0700 (PDT) In-Reply-To: <4A01CF05.1010100@isode.com> References: <4A01CF05.1010100@isode.com> Date: Wed, 6 May 2009 11:56:37 -0700 Message-ID: From: Lisa Dusseault To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 May 2009 04:21:12 -0700 Cc: ops-dir@ietf.org, aaa-doctors@ietf.org, draft-thomson-beep-async@tools.ietf.org, "Ersue, Mehmet \(NSN - DE/Munich\)" , iesg@ietf.org, "ext Thomson, Martin" Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:04:37 -0000 I agree with Mehmet on the general perceptions here. When we publish an Internet Standard that extends another Internet Standard, we are perceived as saying that the later RFC is the one people should implement. The negotiation can be for backwards compatibility, rather than for long-term co-existence with original-BEEP implementations. I also agree that extending an Internet Standard on the Standards Track should demonstrate a higher level of consensus. Lisa On Wed, May 6, 2009 at 10:55 AM, Alexey Melnikov wrote: > Ersue, Mehmet (NSN - DE/Munich) wrote: > >> Dear Martin, >> > > Dear Mehmet, > >>> Sent: Tuesday, May 05, 2009 1:50 AM >>> To: Romascanu, Dan (Dan) >>> Cc: Alexey Melnikov; Ersue, Mehmet (NSN - DE/Munich) >>> Subject: RE: [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt >>> toProposed Standard >>> >>> Thanks for forwarding this on Dan. >>> >>> I'll deal with the smaller comments below, but there are two concerns >>> that I'd like to address up front. >>> >>> =3D=3DUse Case >>> >>> The draft is quite clear on the use case - large volumes of requests th= at >>> take a significant amount of time. =A0I don't think that the draft coul= d be >>> any clearer without numbers. >>> >>> If numbers are necessary for justification, imagine 1000 requests per >>> second with a 50+ second processing time. =A0We've looked at the same p= roblem >>> for HTTP and it starts pushing the limits of what a single machine can >>> handle. =A0Even if the machine could handle the actual processing load,= 50,000 >>> connections stresses most TCP stacks. >>> >>> A single BEEP connection might handle this, but no BEEP stack is requir= ed >>> to support 50,000 channels (the limit is 257), which is what would be >>> required. =A0Mehmet asserts that BEEP concurrency is adequate, but this= is >>> demonstrably not true in this case. >>> >> >> I don't claim that this functionality is not useful. What I mean is that >> the existing features might be already sufficient to solve the same prob= lem >> space and a new feature might not be necessary as an "additional mandato= ry >> standard". >> I would like to have the explanation and reasoning why this is a require= d >> feature and why the existing features are not able to solve the problem = "as >> text in the document", IOW text proving that it is a necessity and not n= ice >> to have. >> > > Noted. I will add an RFC Editor note for this, or the author will revise = the > document to add such text. > >> I don't have anything against this feature if it gets published as an >> Informational RFC. >> However, the document is meant to become a BEEP-bis standard >> and I don't agree to publish it as a mandatory standard, >> > This feature is not mandatory - it is negotiated by the client. So I don'= t > understand why you keep calling this BEEP-bis and "mandatory standard". > >> without the decision of a WG to extend an existing standard, without the >> thorough discussion and development of a WG and without the consensus >> reached in an IETF WG maillist, which is IMO absolutely necessary if we = want >> to extend an existing "IETF standard" with an additional "mandatory stan= dard >> feature". >> > > [snip] > > -- > IETF Application Area Director, > Internet Messaging Team Lead, > JID: same as my email address > > > From dromasca@avaya.com Tue May 12 02:51:17 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16563A6859; Tue, 12 May 2009 02:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] 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 W0-YeqvWpUqB; Tue, 12 May 2009 02:51:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 6CF183A6D14; Tue, 12 May 2009 02:50:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,181,1241409600"; d="scan'208";a="145530215" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 May 2009 05:52:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2009 05:52:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 May 2009 11:52:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dkim-overview-11.txt to Informational RFC Thread-Index: AcnSz6XZm2RKTkM7Q9KnDJFQBrEReQAF6Kiw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dkim-overview-11.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 09:51:18 -0000 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-11.txt Technical Summary This document provides a description of the architecture and functionality for DomainKeys Identified Mail (DKIM). It is intended for those who are adopting, developing, or deploying DKIM. It will also be helpful for those who are considering extending DKIM, either into other areas of use or to support additional features. This overview does not provide information on threats to DKIM or email, or details on the protocol specifics, which can be found in [RFC4686] and [RFC4871], respectively. The document assumes a background in basic email and network security technology and services. Working Group Summary This document is a product of the DKIM WG, and represents the consensus of the WG. The controversies appeared in the development of the protocols that it describes, not in this document. Document Quality The document has been reviewed by the WG. Personnel The document shepherd is Barry Leiba, and the responsible area director is Pasi Eronen. From dromasca@avaya.com Wed May 13 09:03:59 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7279B3A68CC; Wed, 13 May 2009 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] 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 zn7jAw6DwQnE; Wed, 13 May 2009 09:03:58 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B54583A6A7A; Wed, 13 May 2009 09:03:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,188,1241409600"; d="scan'208";a="145693965" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 May 2009 12:05:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 May 2009 12:05:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 18:05:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Extensible Messaging and Presence Protocol (xmpp) Thread-Index: AcnTSfQmei1IW6mzTNKP+kHyt1ENVwAmmwaw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: WG Review: Extensible Messaging and Presence Protocol (xmpp) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 16:03:59 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, May 13, 2009 12:37 AM To: IETF Announcement list Subject: WG Review: Extensible Messaging and Presence Protocol (xmpp)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 19, 2009. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- Last Modified: 2009-04-27 Current Status: Proposed Working Group Chair(s): TBD Area Director(s): Robert Sparks Cullen Jennings Area Advisor: TBD Mailing Lists: General Discussion: xmpp@ietf.org Description of Working Group: The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. XMPP was originally formalized by the XMPP Working Group in 2002-2004, resulting in publication of RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Goals and Milestones: - Deliver rfc3920bis and rfc3921bis to the IESG. - Decide upon a direction for end-to-end encryption. - Decide upon a direction for server-to-server connection reuse. - Define a framework for SIP-XMPP interworking. - Define a solution for end-to-end encryption. - Define a solution for server-to-server connection reuse. From dromasca@avaya.com Thu May 14 23:26:44 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688443A68C9; Thu, 14 May 2009 23:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] 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 m03iAVbHQaLI; Thu, 14 May 2009 23:26:43 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 608A43A6DA6; Thu, 14 May 2009 23:26:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,198,1241409600"; d="scan'208";a="145883220" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 May 2009 02:27:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 May 2009 02:27:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 08:27:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for May 21, 2009 Telechat Thread-Index: AcnU64HUh0J0jKlISmOP7CpjIvwR8AAOjaRQ From: "Romascanu, Dan (Dan)" To: , , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for May 21, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 06:26:44 -0000 =20 Please find below the preliminary agenda of the 5/21 IESG telechat. Please send me your comments, questions, and concerns before 5/20 COB. Thanks and Regards, Dan =20 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tsvwg-rsvp-proxy-proto-09.txt RSVP Extensions for Path-Triggered RSVP Receiver Proxy (Proposed Standard)=20 - 1 of 3=20 Note: Please read the informational document=20 draft-ietf-tsvwg-rsvp-proxy-approaches before this one!=20 Token: Magnus Westerlund o draft-ietf-netlmm-pmip6-ipv4-support-12.txt IPv4 Support for Proxy Mobile IPv6 (Proposed Standard) - 2 of 3=20 Token: Jari Arkko o draft-ietf-dccp-simul-open-08.txt DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal =20 (Proposed Standard) - 3 of 3=20 Token: Lars Eggert 2.1.2 Returning Item o draft-ietf-pkix-3281update-05.txt An Internet Attribute Certificate Profile for Authorization (Proposed Standard) - 1 of 1=20 Token: Tim Polk 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item o draft-groves-megaco-pkgereg-03.txt H.248/MEGACO Registration Procedures (BCP) - 1 of 1=20 Note: IESG - when reviewing this, please consider the topic of if it is=20 alright to register a "public" package when the specification is not publicly available. This came up as an IETF LC comment.=20 Token: Cullen Jennings 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-tcpm-ecnsyn-09.txt Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK=20 Packets (Experimental) - 1 of 3=20 Token: Lars Eggert o draft-ietf-dkim-overview-11.txt DomainKeys Identified Mail (DKIM) Service Overview (Informational) - 2 of 3=20 Token: Pasi Eronen o draft-ietf-tsvwg-rsvp-proxy-approaches-07.txt RSVP Proxy Approaches (Informational) - 3 of 3=20 Note: Read this before the Protocol document=20 Token: Magnus Westerlund 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 3.3.3 For Action o draft-templin-seal-23.txt The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Informational) -=20 1 of 2=20 Note: Brought back to the agenda because of desired status change (now Inf)=20 Token: Jari Arkko o draft-ford-behave-top-06.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 2 of 2=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Yet Another Mail (yam) - 1 of 2 Token: Alexey Melnikov o Extensible Messaging and Presence Protocol (xmpp) - 2 of 2 Token: Cullen Jennings 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From dromasca@avaya.com Mon May 18 02:44:42 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868ED28C19B; Mon, 18 May 2009 02:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] 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 LOhf-sQgGTGS; Mon, 18 May 2009 02:44:37 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E8DB03A68B8; Mon, 18 May 2009 02:44:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="171160737" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 May 2009 05:46:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 May 2009 05:46:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 May 2009 11:46:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mpls-tp-gach-gal-05.txt to Proposed Standard Thread-Index: AcnXE2kQ4+KDF3VcQXic3InoWbZakwAie/1g From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mpls-tp-gach-gal-05.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 09:44:42 -0000 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-gal-05.txt Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points=20 or were there decisions where the consensus was particularly rough?=20 Document Quality Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Loa Andersson is the Document Shepherd for this document. Adrian Farrel is the Responsible Area Director. RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed May 20 03:58:51 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF9928C170; Wed, 20 May 2009 03:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 rroxmUdn+7Fb; Wed, 20 May 2009 03:58:50 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 365D33A6FA4; Wed, 20 May 2009 03:58:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="161882370" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 20 May 2009 07:00:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 May 2009 07:00:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 13:00:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-sip-ua-privacy-08.txt to Informational RFC Thread-Index: AcnYw7WlGp/2RB4IRciKAgeQ0ZlKDQAdl5wg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-sip-ua-privacy-08.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 10:58:51 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-08.txt Technical summary. This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUU) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. Working group summary. There is consensus in the working group to publish this document.=20 Document Quality There has been no specific indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed May 20 04:04:31 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2AD28C0D8; Wed, 20 May 2009 04:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 7NvHW-xPJ8xB; Wed, 20 May 2009 04:04:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0B5973A69D7; Wed, 20 May 2009 04:04:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="171424448" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 May 2009 07:06:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 May 2009 07:06:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 13:05:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-geopriv-sip-lo-retransmission-02.txt to Informational RFC Thread-Index: AcnYwypySm7Zdc0gRc6ssuBNP1P4kgAd7ckQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-geopriv-sip-lo-retransmission-02.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:04:31 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-sip-lo-retransmis sion-02.txt Technical Summary This document explores an ambiguity in the interpretation of the element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity. Working Group Summary This document was produced in order to express the consensus of the GEOPRIV working group on a privacy issue raised by location conveyance in the SIP protocol. There is thus strong consensus within GEOPRIV around the core privacy recommendations in the document. Document Quality The document has been reviewed by key participants from the GEOPRIV, SIP, and privacy community, and its recommendations have been implemented in draft-ietf-sip-location-conveyance-13. Personnel Document Shepherd is Richard Barnes. RFC Editor Note At the end of first paragraph of the Abstract OLD: these ambiguities NEW: this ambiguity IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed May 20 04:06:18 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440F03A6B23; Wed, 20 May 2009 04:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] 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 nY4Y2Vpt06y1; Wed, 20 May 2009 04:06:17 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 5D91F3A6822; Wed, 20 May 2009 04:06:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="171424599" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 May 2009 07:07:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 May 2009 07:07:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 13:07:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-avt-seed-srtp-11.txt to Informational RFC Thread-Index: AcnYwR6LF4w1VefcQtqgxTlShHmYHAAefMOQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-avt-seed-srtp-11.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:06:18 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-11.txt Technical Summary This document describes the use of the SEED [RFC4269] block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) [RFC3711] for providing confidentiality for the Real-time Transport Protocol (RTP) [RFC3550] traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP) [RFC3550].=20 Working Group Summary The document has been reviewed by the AVT working group to ensure consistency with SRTP. Document Quality There are implementations of SEED and this draft specifies how to use it for SRTP Personnel Roni Even is the document shepherd. Cullen Jennings is the Responsible AD.=20 Review was provided by David McGrew and Eric Rescorla.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Sun May 24 08:29:03 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57CE28C0FB; Sun, 24 May 2009 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] 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 z1XwKvP6PTo6; Sun, 24 May 2009 08:28:57 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EEF163A6882; Sun, 24 May 2009 08:28:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,240,1241409600"; d="scan'208";a="171795375" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 May 2009 11:30:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 May 2009 11:30:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 May 2009 17:30:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP Thread-Index: AcnaP4lUW8erJ0OxT6KtiwORTsuLhACRL4TA From: "Romascanu, Dan (Dan)" To: , , , Subject: [AAA-DOCTORS] FW: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 15:29:04 -0000 I believe that this BCP may have specific implications for each on of the directorates and review teams in OPS, so I suggest that at least one reviewer goes through it in each team and sends relevant LC comments.=20 Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, May 21, 2009 9:09 PM To: IETF-Announce Subject: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP=20 The IESG has received a request from an individual submitter to consider the following document: - 'Guidance on Interoperation and Implementation Reports ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dusseault-impl-reports-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 17620&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Sun May 24 09:44:04 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176E43A6E51; Sun, 24 May 2009 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 P8k+8Z7ZRWgA; Sun, 24 May 2009 09:44:03 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 249F428C16B; Sun, 24 May 2009 09:44:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,240,1241409600"; d="scan'208";a="171797123" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 May 2009 12:45:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 May 2009 12:45:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 May 2009 18:45:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dnsext-dnsproxy-05.txt to BCP Thread-Index: AcnbnbfZMXL3u3mPQ3md5nc8ugwWqAA8UM3w From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dnsext-dnsproxy-05.txt to BCP X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 16:44:04 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-05.txt Technical Summary This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary The consensus for this document is real strong. Document Quality This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon May 25 07:20:46 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3162C3A6D0A; Mon, 25 May 2009 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74] 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 C1KjAcB-Ms5P; Mon, 25 May 2009 07:20:40 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 69E3F3A6AE5; Mon, 25 May 2009 07:20:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,244,1241409600"; d="scan'208";a="162300975" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 25 May 2009 10:22:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 May 2009 10:22:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 16:22:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ford-behave-top-06.txt to Informational RFC Thread-Index: AcndQbnBcEc3c7vAQhextyHHkuAntwAAmHXA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ford-behave-top-06.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 14:20:46 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ford-behave-top-06.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.=20 Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. =20 Working Group Summary This is an RFC-editor independent submission.=20 Document Quality This is an RFC-editor independent submission. Personnel Magnus Westerlund was the responsible AD for the RFC 3932=20 recommendations. RFC Editor Note The IESG thinks that this work is related to IETF work done in WG BEHAVE, but this does not prevent publishing. IRTF Note (Insert IRTF Note here or remove section) IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon May 25 10:39:05 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1053A683B; Mon, 25 May 2009 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 lo7TTCU-TIDZ; Mon, 25 May 2009 10:39:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 600733A69B7; Mon, 25 May 2009 10:39:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,245,1241409600"; d="scan'208";a="171868334" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 May 2009 13:40:40 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 May 2009 13:40:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 19:40:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mmusic-sdp-capability-negotiation-10.txt to Proposed Standard Thread-Index: Acna/gdvPDfHnQY7TZKjXkmjTRxSYwCYbDNQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mmusic-sdp-capability-negotiation-10.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 17:39:05 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-neg otiation-10.txt Technical Summary This document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. =20 Working Group Summary The MMUSIC Working Group has consensus to publish this document as a Proposed Standard. =20 Document Quality This mechanism was specifically designed to allow some shortcomings seen in the field that could help deploy secure RTP (SRTP). See page 11 of the document, these SDP extensions allow an SDP agent to offer both RTP and SRTP as alternatives, with SRTP being the preferred option using the Offer/Answer mechanism. =20 Personnel The Proto Shepherd is Jean-Francois Mule, and the Responsible Area Director is Cullen Jennings. RFC Editor Note (Insert RFC Editor Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon May 25 12:00:38 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E114D3A7011; Mon, 25 May 2009 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 WDtVKwP54wQ5; Mon, 25 May 2009 12:00:32 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 64C5A3A7019; Mon, 25 May 2009 12:00:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,245,1241409600"; d="scan'208";a="162315884" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 25 May 2009 15:02:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 May 2009 15:02:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 21:01:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-ippm-more-twamp-02.txt to Proposed Standard Thread-Index: AcnZT1BQtUFA0unnS5SP+Sk8sL5E8gEG8+fg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-ippm-more-twamp-02.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 19:00:39 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-01.txt Technical Summary The IETF has completed its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a simple extension to TWAMP, the option to use different security modes in the TWAMP- Control and TWAMP-Test protocols. Working Group Summary This document was discussed at various IETF meetings in 2008. There was no controversy in the WG process. Consensus was smooth. Document Quality At least 3 vendors are implementing TWAMP. Personnel The document shepherd is Henk Uijterwaal (henk@ripe.net). Lars Eggert (lars.eggert@nokia.com) reviewed the ID for the IESG. From dromasca@avaya.com Wed May 27 07:59:03 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EB33A6DA2; Wed, 27 May 2009 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] 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 MvCEEFSK5Qxa; Wed, 27 May 2009 07:59:02 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id F14883A6C9A; Wed, 27 May 2009 07:59:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241409600"; d="scan'208";a="162522122" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 27 May 2009 10:59:46 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 May 2009 10:59:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 16:59:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-crocker-email-arch-13.txt to Proposed Standard Thread-Index: Acne2v4ZP51U9Ry/QZuh00DslX9R2AAAJe3Q From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-crocker-email-arch-13.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 14:59:03 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crocker-email-arch-13.txt Technical Summary Public discussion of the Internet Mail service often lacks common terminology and a common frame of reference for these components and their activities. Having a common reference model and terminology makes a basic difference when talking about problems with the service, changes in policy, or enhancement to the service's functionality. This document offers an enhanced Internet Mail architecture that targets description of the existing service, in order to facilitate clearer and more efficient technical, operations and policy discussions about email. Working Group Summary This document was discussed within the mail community on the mailing lists dedicated to SMTP and the Mail Format. Some of the terms came about as a compromise after long discussions, but rough consensus was achieved on all points. Members of the working groups dealing with IMAP and LEMONADE were aware of this effort, but it was not an appropriate topic for those working groups to place on their charters. There is no other current working group dealing with the mail system in general. Document Quality This document does not create a protocol specification. The acknowledgments indicate that Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful insight on the framework and details of the original drafts. A number of other people have provided additional reviews and insights. Personnel Who is the Document Shepherd for this document? Tony Hansen Who is the Responsible Area Director? Chris Newman and Alexey Melnikov have reviewed this document for IESG. From dromasca@avaya.com Thu May 28 07:33:46 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B0828C1DC; Thu, 28 May 2009 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 oolMNqHKj8Iw; Thu, 28 May 2009 07:33:46 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 904D83A69A2; Thu, 28 May 2009 07:33:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,265,1241409600"; d="scan'208";a="162648131" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 28 May 2009 10:35:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 May 2009 10:35:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 16:34:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dnsext-dnsproxy-05.txt to BCP Thread-Index: AcnfibhfDB8aBRA9R1Gd8gYiYIqF+AAF7QxA From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dnsext-dnsproxy-05.txt to BCP X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 14:33:46 -0000 =20 - 'DNS Proxy Implementation Guidelines ' as a BCP This document is the product of the DNS Extensions Working Group.=20 The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-05.txt Technical Summary This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary The consensus for this document is real strong. Document Quality This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Thu May 28 08:05:43 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0644A28C26D; Thu, 28 May 2009 08:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 qD+QIO7hycjr; Thu, 28 May 2009 08:05:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id CBA8928C24B; Thu, 28 May 2009 08:05:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,265,1241409600"; d="scan'208";a="172224296" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 May 2009 11:07:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 May 2009 11:07:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 17:06:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-sip-outbound-18.txt to Proposed Standard Thread-Index: Acne9/zDUEL5DupqSniAMGTdZGhLzQAradlA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-sip-outbound-18.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 15:05:43 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-18.txt Technical Summary This document defines an 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, requiring 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. Both were eventually resolved by a widely-accepted compromises. Additional work is being pursued in SIPCORE to allow the use of the keepalive mechanism independently of the outbound mechanism.=20 Document Quality There have been implementations of previous versions of this draft testing at SIPit events since 2005. Personnel Dean Willis is the document shepherd with significant assistance from Francois Audet. Robert Sparks is the responsible area director. From dromasca@avaya.com Thu May 28 09:42:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FA63A691E; Thu, 28 May 2009 09:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 BLUBBu0LAXZt; Thu, 28 May 2009 09:42:26 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9A2553A6DF0; Thu, 28 May 2009 09:42:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,266,1241409600"; d="scan'208";a="147038752" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 May 2009 12:44:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 May 2009 12:44:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 18:43:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dkim-ssp-10.txt to Proposed Standard Thread-Index: AcnfscgY9gx4MagoQEazjiDylPL78gAAZOgg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dkim-ssp-10.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 16:42:27 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-10.txt Technical Summary DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail, and how other hosts can access that record. Working Group Summary draft-ietf-dkim-ssp-07 is the 8th official WG draft, following on from 3 iterations of an individual submission draft-allman-dkim-ssp with the -00 version dating back to January 2006. The current draft has passed WGLC with solid support in the DKIM WG. Some minor editorial changes were make post-WGLC based on (a few) comments received on the -05 draft. The DKIM WG used the rt.psg.com tracker for its work (queue=3Ddkim) and processed O(50) issues for this document over the period. Document Quality The document has undergone thorough review in the WG resulting in various revisions, typically removing features or renaming elements of the protocol, however, the basic core feature of ADSP has remained stable all through the process. Personnel Stephen Farrell (stephen.farrell@cs.tcd.ie) is the document shepherd. The responsible AD is Pasi Eronen. From dromasca@avaya.com Fri May 29 04:48:52 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E173A6C04; Fri, 29 May 2009 04:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 PQ1y9dhY69K4; Fri, 29 May 2009 04:48:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 779663A6D46; Fri, 29 May 2009 04:48:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,271,1241409600"; d="scan'208";a="172323655" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 May 2009 07:49:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 May 2009 07:49:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 May 2009 13:49:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PREMINARY Agenda and Package for June 4, 2009 Telechat Thread-Index: Acnf45hnmtVM84d1RSqsAXieslWwFQAb4cOQ From: "Romascanu, Dan (Dan)" To: , , , Subject: [AAA-DOCTORS] FW: PREMINARY Agenda and Package for June 4, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 11:48:53 -0000 =20 Please find below the preliminary agenda of the 6/4 IESG telechat. Please send me your questions, comments and concerns about the relevant documents and WG charter brought to approval before Wednesday 6/3 COB.=20 Thanks and Regards, Dan --------------------------------------- 2.1 WG Submissions 2.1.1 New Item o draft-ietf-dkim-ssp-10.txt DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)=20 (Proposed Standard) - 1 of 7=20 Note: Document shepherd is Stephen Farrell (stephen.farrell@cs.tcd.ie) =20 Token: Pasi Eronen o draft-ietf-sip-outbound-18.txt Managing Client Initiated Connections in the Session Initiation Protocol=20 (SIP) (Proposed Standard) - 2 of 7=20 Token: Robert Sparks o draft-ietf-mmusic-sdp-capability-negotiation-10.txt SDP Capability Negotiation (Proposed Standard) - 3 of 7=20 Note: Proto Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)=20 Token: Cullen Jennings o draft-ietf-netlmm-pmip6-ipv4-support-12.txt IPv4 Support for Proxy Mobile IPv6 (Proposed Standard) - 4 of 7=20 Token: Jari Arkko o draft-ietf-ippm-more-twamp-02.txt More Features for the Two-Way Active Measurement Protocol - TWAMP (Proposed=20 Standard) - 5 of 7=20 Token: Lars Eggert o draft-ietf-dkim-rfc4871-errata-05.txt RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update (Proposed=20 Standard) - 6 of 7=20 Token: Pasi Eronen o draft-ietf-dnsext-dnsproxy-05.txt DNS Proxy Implementation Guidelines (BCP) - 7 of 7=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-crocker-email-arch-13.txt Internet Mail Architecture (Proposed Standard) - 1 of 1=20 Note: Tony Hansen is document shepherd.=20 Token: Alexey Melnikov 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-avt-seed-srtp-11.txt The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport=20 Protocol (SRTP (Informational) - 1 of 2=20 Token: Cullen Jennings o draft-ietf-geopriv-sip-lo-retransmission-02.txt Implications of 'retransmission-allowed' for SIP Location Conveyance (Informational) - 2 of 2=20 Token: Cullen Jennings 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-ietf-sip-ua-privacy-08.txt UA-Driven Privacy Mechanism for SIP (Informational) - 1 of 1=20 Token: Cullen Jennings 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-ford-behave-top-06.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 1 of 1=20 Token: Magnus Westerlund 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 1 Token: Magnus Westerlund 4.2.2 Proposed for Approval NONE From aland@deployingradius.com Sat May 30 00:29:27 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCAE28C0D9 for ; Sat, 30 May 2009 00:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599] 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 W+B6zHIzsyk4 for ; Sat, 30 May 2009 00:29:27 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id C62D13A6EE8 for ; Sat, 30 May 2009 00:29:26 -0700 (PDT) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B842512343D2; Sat, 30 May 2009 09:31:09 +0200 (CEST) Message-ID: <4A20E0BC.2080301@deployingradius.com> Date: Sat, 30 May 2009 09:31:08 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: secdir-secretary@mit.edu, raft-ietf-dnsext-dnsproxy.all@tools.ietf.org, aaa-doctors@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 31 May 2009 02:00:26 -0700 Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 07:29:28 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Over all, the document appears to be clear. I wonder about the following text in section 4.5, however: NB: any DNS proxy (such as those commonly found in WiFi hotspot "walled gardens") which transparently intercepts all DNS queries, and which returns unsigned responses to signed queries, will also cause TSIG authentication failures. The problem with WiFi hotspot DNS proxies is much, much, worse than this simple paragraph would suggest. There are issues found in in those deployments that are not discussed in this document. I will summarize them here: Issue: responding to all DNS requests with the IP of the hotspot Goal: to guide all client traffic to the hotspot Background: Many client machines have VPN software that checks for the existence of "internal" corporate DNS names. If the names resolve, the client is assumed to be "within" the corporate network. If the name does not resolve, the client is assumed to be elsewhere, and the VPN software behaves differently. DNS proxies that return an answer for all names result in the client erroneously believing it is in the "internal" network. Various things then fail in weird and wonderful ways. Even when VPN software doesn't exist, this practice can cause other problems. A commonly used web browser (I.E. from a major vendor) can cache the results of DNS queries at the application layer. This information is cached even across DHCP lease assignments from a new subnet, where DNS caches are usually flushed. The result is that the web browser cannot view the first web page that the user tries to visit. The captive portal page is always shown instead. Suggestion: DNS proxies MUST NOT respond with an answer if the name is not resolvable. DNS proxies MUST NOT synthesize an answer. Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1) Goal: to catch *different* kinds of traffic than the previous issue (this is no explanation, I've never had one explained to me in a way I understand) Background: Some proxies return synthetic responses with "fake" IP addresses. While 1.1.1.1 is not currently allocated, it may be in the future. Using it is a bad choice. In fact, this whole practice is completely wtong. Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer. The above suggestions might be a little strong. There are valid cases where a proxy inside of a corporate network might need to synthesize incorrect answers. These situations are better described as "internal corporate policy". i.e. Notwithstanding the suggestions above, if you want to break your own network, there are often valid reasons for doing so. Alan DeKok. From dromasca@avaya.com Sun May 31 03:21:37 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC2428C0FF; Sun, 31 May 2009 03:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] 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 0qwKRdMGTKVB; Sun, 31 May 2009 03:21:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 12F193A6836; Sun, 31 May 2009 03:21:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,278,1241409600"; d="scan'208";a="172470599" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 May 2009 06:23:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 31 May 2009 06:23:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 May 2009 12:22:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter Update for Geopriv WG Thread-Index: Acnf9osOnnQG6QX+TWyrRlHzOS1mgwB4yYRw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Charter Update for Geopriv WG X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 10:21:37 -0000 =20 Please let me know if you have any comments or concerns.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, May 29, 2009 3:44 AM To: IESG IESG Cc: Richard Barnes Subject: Charter Update for Geopriv WG bcc to iesg-secretary Can you please put this Charter on the agenda for the next IESG call. =20 It should go in the "4.1.1 Proposed for IETF Review" section. ---------------------------- The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. =20 However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Goals and Milestones Done Discuss initial geopriv scenarios and application requirements i- d's Done Discuss initial geographic location privacy and security requirements i-d. Done Initial i-d on geographic information protocol design, including privacy and security techniques. Done Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. Done Submit geopriv scenarios and application requirements to IESG for publication as Informational RFCs Done Submit security/privacy requirements I-D to IESG for publication as Informational RFC. Done Submit PIDF-LO basic geopriv object draft as a PS Done Initial Common Rules base object draft Done Initial Common Rules GEOPRIV object draft Done Submit DHCP Civil draft as a PS Done Resubmit Conveying Location Objects in RADIUS and Diameter to =20 the IESG for publication as PS Done Submit Additional Civic PIDF-LO types (updating 4119) to the =20 IESG for publication as PS Done Submit minimal HTTP based protocol satisfying baseline =20 requirements specified in the Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as PS Done Submit PIDF-LO Usage Clarifications and Recommendations =20 (updating 4119) to the IESG for publication as PS Done Submit Layer 7 Location Conveyance Protocol Problem Statement =20 and Requirements to the IESG for publication as Informational Done Submit recommendations for representing civic addresses in =20 PIDF-LO to the IESG for publication as BCP Done Submit Recommendations for Retransmission in SIP Location =20 Conveyance to the IESG for publication as Informational Done Submit Requirements for Location by Reference Protocols to =20 the IESG for publication as Informational Done Submit a LIS Discovery Mechanism to the IESG for publication as a PS Jun 2009 Resubmit Geolocation Policy to the IESG for publication as PS Sep 2009 Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Sep 2009 Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Dec 2009 Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Dec 2009 Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Dec 2009 Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS From dromasca@avaya.com Sun May 31 03:41:43 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9876628C16B; Sun, 31 May 2009 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 BgtirjpCZGcm; Sun, 31 May 2009 03:41:42 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 194A128C1AF; Sun, 31 May 2009 03:41:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,278,1241409600"; d="scan'208";a="172471155" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 May 2009 06:43:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 31 May 2009 06:43:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 May 2009 12:43:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Recharter of Point-to-Point Protocol Extensions (pppext) Thread-Index: AcngmE3qjL7iPgEURy+T2eCe84QNwgBRDPGg From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Internal WG Review: Recharter of Point-to-Point Protocol Extensions (pppext) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 10:41:43 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, May 29, 2009 11:00 PM To: iesg@ietf.org; iab@iab.org; james.d.carlson@sun.com Subject: Internal WG Review: Recharter of Point-to-Point Protocol Extensions (pppext)=20 A new charter for the Point-to-Point Protocol Extensions working group (pppext) in the Internet Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat Point-to-Point Protocol Extensions (pppext) -------------------------------------------- Last Modified: 2009-05-29 Additional information is available at tools.ietf.org/wg/pppext Chair(s): James Carlson Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: pppext@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pppext In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/pppext/index.html Description of Working Group: The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The PPPEXT working exists to provide a forum for asking clarifications about the existing specifications and to defend against enhancements of questionable value. The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required. The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate. Goals and Milestones: Done Advance SDL draft to Experimental Done Add VLAN support to BCP (RFC 1638) and recycle at Proposed=20 Standard From dromasca@avaya.com Sun May 31 08:04:45 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E1928C0F9; Sun, 31 May 2009 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 uOHapKI6hwJ7; Sun, 31 May 2009 08:04:44 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 034CE3A6EA3; Sun, 31 May 2009 08:04:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,279,1241409600"; d="scan'208";a="162891984" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 31 May 2009 11:06:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2009 11:06:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 May 2009 17:06:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) Thread-Index: AcnfyyZQjbURAxzETJWn8JgyexRBTQCNhufw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Internal WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 15:04:45 -0000 =20 Please find below the proposal for re-chartering behave. Let me know before Wednesday 6/3 if there are any questions or concerns.=20 Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Thursday, May 28, 2009 10:31 PM To: iesg@ietf.org; iab@iab.org; dwing@cisco.com; dthaler@microsoft.com Subject: Internal WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)=20 A new charter for the Behavior Engineering for Hindrance Avoidance working group (behave) in the Transport Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Last Modified: 2009-05-27 Current Status: Active Working Group Chair(s): Dan Wing Dave Thaler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end- to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security that is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. The goal of this work is to encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function services is intended to service a specific IPv4 network using either private or public IPv4 addresses. Because this scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. The WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The fundamental parts of ICMP are also required to work. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Jun 2009 Submit BCP document for SCTP NAT behavior Done Submit standards-track relay protocol Done Determine relative prioritization of the four translation cases. =20 Sep 2009 Submit standards-track document for relaying of a TCP bytestream Jun 2009 Submit standard-track document of an IPv6 relay protocol to IESG Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Jul 2009 Submit standards-track TURN-URI document Sep 2009 Submit informational for framework for IPv6/IPv4 translation document Sep 2009 Submit standards-track stateless IPv6/IPv4 translation document Sep 2009 Submit standards-track stateful IPv6/IPv4 translation document Sep 2009 Submit standards-track DNS rewriting for IPv6/IPv4 translation document Nov 2009 Submit standards-track FTP ALG for IPv6/IPv4 translation document Nov 2009 Submit standards-track IPv6 prefix for IPv6/IPv4 translator document Mar 2010 Submit BCP large scale NAT requirements document=20