From owner-ietf-ppp@merit.edu Tue Dec 9 12:30:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04362 for ; Tue, 9 Dec 2003 12:30:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BFF19121A; Tue, 9 Dec 2003 12:30:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B5089123B; Tue, 9 Dec 2003 12:30:21 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A11199121A for ; Tue, 9 Dec 2003 12:30:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72E165DDCD; Tue, 9 Dec 2003 12:30:17 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by segue.merit.edu (Postfix) with ESMTP id F2E855DDAC for ; Tue, 9 Dec 2003 12:30:13 -0500 (EST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hB9HUD6t234328 for ; Tue, 9 Dec 2003 12:30:13 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id hB9HUBxm130500 for ; Tue, 9 Dec 2003 10:30:11 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hB9HTKKn024592 for ; Tue, 9 Dec 2003 12:29:20 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hB9HTKbZ024587 for ; Tue, 9 Dec 2003 12:29:20 -0500 Message-Id: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> To: ietf-ppp@merit.edu Subject: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt Date: Tue, 09 Dec 2003 12:29:20 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The IESG has reviewed the document and did not have any issue with the content of the document per se. However, the follow issue was raised: This document has a normative reference to RFC 2153, which is an informational document. Per 2026, Standards Track documents can't have normative references to informational documents. The following options were mentioned as ways forward: - Moving to reclassify 2153 as Standards Track. - Making 2153 an informative reference. (doable, but would require some text shuffling) - Moving this draft to Informational track. I think there was a slight preference within the IESG for the latter step, but we can go with whatever the WG decides it wants to do. Opinions? Thomas From owner-ietf-ppp@merit.edu Tue Dec 9 13:21:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06468 for ; Tue, 9 Dec 2003 13:21:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18F2E9123B; Tue, 9 Dec 2003 13:21:39 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D99EE9123C; Tue, 9 Dec 2003 13:21:38 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C54509123B for ; Tue, 9 Dec 2003 13:21:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD2195DE63; Tue, 9 Dec 2003 13:21:37 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail6.L-3com.com (mail6.l-3com.com [148.104.5.4]) by segue.merit.edu (Postfix) with ESMTP id BF9AD5DDE8 for ; Tue, 9 Dec 2003 13:21:36 -0500 (EST) Received: from avgw2.l-3com.com (avgw2.l-3com.com [166.20.84.115]) by mail6.L-3com.com (8.11.7+Sun/8.11.7) with SMTP id hB9ILNq01185; Tue, 9 Dec 2003 12:21:23 -0600 (CST) Received: from l3c-xchg-cse.mail.cse.l-3com.com ([166.20.19.57]) by avgw2.l-3com.com (SAVSMTP 3.1.2.35) with SMTP id M2003120913212102270 ; Tue, 09 Dec 2003 13:21:21 -0500 Received: by l3c-xchg-cse.mail.cse.l-3com.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 13:21:21 -0500 Message-ID: <038850B3A7FAD411B8C800B0D049DE9505F2BE45@l3c-xchg-cse.mail.cse.l-3com.com> From: richard.winslow@L-3com.com To: narten@us.ibm.com Cc: ietf-ppp@merit.edu Subject: RE: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt Date: Tue, 9 Dec 2003 13:21:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas: My preference is option 2 (making the reference informative), but I can go along with whatever James Carlson and the rest of you decide. Thanks, Rich Winslow -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, December 09, 2003 12:29 PM To: ietf-ppp@merit.edu Subject: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt The IESG has reviewed the document and did not have any issue with the content of the document per se. However, the follow issue was raised: This document has a normative reference to RFC 2153, which is an informational document. Per 2026, Standards Track documents can't have normative references to informational documents. The following options were mentioned as ways forward: - Moving to reclassify 2153 as Standards Track. - Making 2153 an informative reference. (doable, but would require some text shuffling) - Moving this draft to Informational track. I think there was a slight preference within the IESG for the latter step, but we can go with whatever the WG decides it wants to do. Opinions? Thomas From owner-ietf-ppp@merit.edu Tue Dec 9 15:08:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11537 for ; Tue, 9 Dec 2003 15:08:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C35869123D; Tue, 9 Dec 2003 15:08:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 933C59123F; Tue, 9 Dec 2003 15:08:03 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7B609123D for ; Tue, 9 Dec 2003 15:08:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B0085DDB1; Tue, 9 Dec 2003 15:08:02 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 0CF4F5DDAC for ; Tue, 9 Dec 2003 15:08:02 -0500 (EST) Received: from lmf.ericsson.se (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7D71C6A902; Tue, 9 Dec 2003 22:07:45 +0200 (EET) Message-ID: <3FD62A78.6060704@lmf.ericsson.se> Date: Tue, 09 Dec 2003 22:03:04 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt References: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> In-Reply-To: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thomas Narten wrote: > The following options were mentioned as ways forward: > > - Moving to reclassify 2153 as Standards Track. I didn't realize reclassification is an option. Does that involve re-publishing the RFC with a different number, the whole RFC approval process? > - Making 2153 an informative reference. (doable, but would > require some text shuffling) Hmm.... perhaps you can do it but I wonder if its too much of a stretch. The draft says that it uses the 2153 OUI values. Yes, they are mostly IEEE numbers but not in the case of CF0000 values. I'm not sure how you would avoid having 2153 define at least partially the semantics and allocation policy for one of the fields in the draft. > - Moving this draft to Informational track. I'm not sure why 2153 was put out as Informational. But if the reclassification is a too lengthy process and making the reference informative too hard, moving this draft to informational track may be the only option left. --Jari From owner-ietf-ppp@merit.edu Tue Dec 9 15:18:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12808 for ; Tue, 9 Dec 2003 15:18:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 046579123F; Tue, 9 Dec 2003 15:18:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C465491240; Tue, 9 Dec 2003 15:18:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B7149123F for ; Tue, 9 Dec 2003 15:18:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78F325DE81; Tue, 9 Dec 2003 15:18:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C01BD5DE27 for ; Tue, 9 Dec 2003 15:18:07 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB9KI5Ph017092; Tue, 9 Dec 2003 13:18:05 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hB9KI4bx021334; Tue, 9 Dec 2003 15:18:04 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id hB9KHi3L009493; Tue, 9 Dec 2003 15:17:44 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10/Submit) id hB9KHimg009490; Tue, 9 Dec 2003 15:17:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16342.11752.732387.533503@gargle.gargle.HOWL> Date: Tue, 9 Dec 2003 15:17:44 -0500 From: James Carlson To: Jari Arkko Cc: Thomas Narten , ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt In-Reply-To: Jari Arkko's message of 9 December 2003 22:03:04 References: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> <3FD62A78.6060704@lmf.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jari Arkko writes: > > - Making 2153 an informative reference. (doable, but would > > require some text shuffling) > > Hmm.... perhaps you can do it but I wonder if its too > much of a stretch. The draft says that it uses the > 2153 OUI values. Yes, they are mostly IEEE numbers > but not in the case of CF0000 values. I don't think that's so much a problem -- this draft can reference IANA for those values directly. The CF0000 values are fixed by IANA, regardless of what 2153 might say. > > - Moving this draft to Informational track. > > I'm not sure why 2153 was put out as Informational. I *think* the reasoning looked something like this: These are, by definition, vendor-proprietary extensions. There's no hope that vendors will interoperate on proprietary extensions (if they did, such things would be better issued as public documents), so any document that depends on such interoperability won't advance on standards track. The small flaw behind that logic, at least in my mind, is that properly agreeing-to-disagree (per the protocol, where each side is from a different vendor) *is* an instance of "interoperability," so long as the link doesn't fail or behave badly because of it. There's a fuzzy line here -- the mechanism for extension is itself reasonably standards-track material, but any use of the mechanism would (necessarily) be proprietary. So what do you do? All that said, I'm not too worried about the problem. If the simplest solution is to make this Informational as well (and I think it is), then that's certainly fine by me. It's publication in a fixed form that allows reference ("here's what you do if you're doing one of these") that matters most to me. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Dec 9 15:47:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15844 for ; Tue, 9 Dec 2003 15:47:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B20591241; Tue, 9 Dec 2003 15:47:06 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AC7B91242; Tue, 9 Dec 2003 15:47:05 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F79B91241 for ; Tue, 9 Dec 2003 15:47:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18D9C5DF16; Tue, 9 Dec 2003 15:47:05 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id A6F965DDE1 for ; Tue, 9 Dec 2003 15:47:04 -0500 (EST) Received: from lmf.ericsson.se (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8732F6A902; Tue, 9 Dec 2003 22:47:03 +0200 (EET) Message-ID: <3FD633AE.2020303@lmf.ericsson.se> Date: Tue, 09 Dec 2003 22:42:22 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Cc: Thomas Narten , ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt References: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> <3FD62A78.6060704@lmf.ericsson.se> <16342.11752.732387.533503@gargle.gargle.HOWL> In-Reply-To: <16342.11752.732387.533503@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > All that said, I'm not too worried about the problem. If the simplest > solution is to make this Informational as well (and I think it is), > then that's certainly fine by me. It's publication in a fixed form > that allows reference ("here's what you do if you're doing one of > these") that matters most to me. Agreed. Given this, my point below is pretty academic. But I just wanted to respond on: > There's a fuzzy line here -- the mechanism for extension is itself > reasonably standards-track material, but any use of the mechanism > would (necessarily) be proprietary. So what do you do? Yes. I think this is perfectly normal. The escape hatch is standard, but what happens when you go outside it is not. Most modern protocols with potential local extension needs have a standardized way to do it. L2TP, Diameter, ... and in many cases there has been a lot of debate exactly how easy or hard such extensibility should be made. Most often the extensibility has been pretty strictly controlled. --Jari From owner-ietf-ppp@merit.edu Tue Dec 9 16:17:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17790 for ; Tue, 9 Dec 2003 16:17:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B46A591242; Tue, 9 Dec 2003 16:17:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C08791243; Tue, 9 Dec 2003 16:17:45 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30FC391242 for ; Tue, 9 Dec 2003 16:17:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14B475DDE1; Tue, 9 Dec 2003 16:17:44 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 8B0F75DE9C for ; Tue, 9 Dec 2003 16:17:43 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB9LHeUP025911; Tue, 9 Dec 2003 13:17:41 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hB9LHeIr008016; Tue, 9 Dec 2003 16:17:40 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id hB9LHK3L009669; Tue, 9 Dec 2003 16:17:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10/Submit) id hB9LHKZC009666; Tue, 9 Dec 2003 16:17:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16342.15328.98884.694753@gargle.gargle.HOWL> Date: Tue, 9 Dec 2003 16:17:20 -0500 From: James Carlson To: Jari Arkko Cc: Thomas Narten , ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt In-Reply-To: Jari Arkko's message of 9 December 2003 22:42:22 References: <200312091729.hB9HTKbZ024587@rotala.raleigh.ibm.com> <3FD62A78.6060704@lmf.ericsson.se> <16342.11752.732387.533503@gargle.gargle.HOWL> <3FD633AE.2020303@lmf.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jari Arkko writes: > > There's a fuzzy line here -- the mechanism for extension is itself > > reasonably standards-track material, but any use of the mechanism > > would (necessarily) be proprietary. So what do you do? > > Yes. I think this is perfectly normal. The escape hatch is standard, > but what happens when you go outside it is not. Most modern protocols > with potential local extension needs have a standardized way to do > it. L2TP, Diameter, ... and in many cases there has been a lot > of debate exactly how easy or hard such extensibility should be > made. Most often the extensibility has been pretty strictly > controlled. Right, and it was on this point ("standard support of non-standard bits") that I asked to hear if there were any IESG direction or policies, since I suspect that others have seen advancement issues here. It'd be really nice if all the protocols needing to provide such features did it in a similar way. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Dec 9 19:44:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26812 for ; Tue, 9 Dec 2003 19:44:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C88B91254; Tue, 9 Dec 2003 19:42:51 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55B9191253; Tue, 9 Dec 2003 19:42:51 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A20691254 for ; Tue, 9 Dec 2003 19:42:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 709F35DF16; Tue, 9 Dec 2003 19:42:47 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id DB69D5DF23 for ; Tue, 9 Dec 2003 19:42:46 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBA0girE312606; Tue, 9 Dec 2003 19:42:44 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-199-106.mts.ibm.com [9.65.199.106]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id hBA0ghCi050916; Tue, 9 Dec 2003 17:42:43 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hBA0fJk13968; Tue, 9 Dec 2003 19:41:19 -0500 Message-Id: <200312100041.hBA0fJk13968@cichlid.raleigh.ibm.com> To: James Carlson Cc: Jari Arkko , ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt In-Reply-To: Message from james.d.carlson@sun.com of "Tue, 09 Dec 2003 16:17:20 EST." <16342.15328.98884.694753@gargle.gargle.HOWL> Date: Tue, 09 Dec 2003 19:41:19 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James Carlson writes: > Right, and it was on this point ("standard support of non-standard > bits") that I asked to hear if there were any IESG direction or > policies, since I suspect that others have seen advancement issues > here. It'd be really nice if all the protocols needing to provide > such features did it in a similar way. If I understand your question, its about interoperability testing for non-standard features. This doesn't come up all that much (partly I guess because not that many documents advance in the first place...). But in the past, I know there have been cases where the negotiation process itself was standards track and testable for interoperability, but the specific methods that were negotiated were not. Isn't this the case with PPP compression, for instance? I think IPComp (RFC 3173) also took this approach. Thomas From owner-ietf-ppp@merit.edu Wed Dec 10 08:25:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11088 for ; Wed, 10 Dec 2003 08:25:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2E5191246; Wed, 10 Dec 2003 08:25:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E8B091248; Wed, 10 Dec 2003 08:25:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63C5C91246 for ; Wed, 10 Dec 2003 08:25:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 491355DE77; Wed, 10 Dec 2003 08:25:09 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AAF9D5DE68 for ; Wed, 10 Dec 2003 08:25:08 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBADP5Ph001489; Wed, 10 Dec 2003 06:25:05 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hBADP5bx003940; Wed, 10 Dec 2003 08:25:05 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id hBADOiCT001460; Wed, 10 Dec 2003 08:24:44 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.10+Sun/8.12.10/Submit) id hBADOiRM001457; Wed, 10 Dec 2003 08:24:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16343.7836.839738.98017@gargle.gargle.HOWL> Date: Wed, 10 Dec 2003 08:24:44 -0500 From: James Carlson To: Thomas Narten Cc: Jari Arkko , ietf-ppp@merit.edu Subject: Re: IESG Evaluation of draft-ietf-pppext-vendor-protocol-01.txt In-Reply-To: Thomas Narten's message of 9 December 2003 19:41:19 References: <"Message from james.d.carlson"@sun.com> <16342.15328.98884.694753@gargle.gargle.HOWL> <200312100041.hBA0fJk13968@cichlid.raleigh.ibm.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thomas Narten writes: > If I understand your question, its about interoperability testing for > non-standard features. This doesn't come up all that much (partly I > guess because not that many documents advance in the first > place...). But in the past, I know there have been cases where the > negotiation process itself was standards track and testable for > interoperability, but the specific methods that were negotiated were > not. Isn't this the case with PPP compression, for instance? That's not quite the same. With PPP Compression (CCP), the methods are mostly documented in RFCs, and very few completely undocumented ones are ever seen in the wild. Granted, most (all?) of the documented methods have onerous licensing and IPR issues, but interoperability among multiple independent implementations is certainly not unknown. The goal of this draft is rather different. It's explicitly carving out a space for vendor-proprietary features, and, unlike CCP, there's no expectation that there'll ever be interoperable versions of these things, at least for large values of "interoperable," nor any open documentation of them. What the draft does is set a lower bar -- it defines a way that vendor-proprietary extensions can meet out in the field and not just explode on contact. The current state-of-the-art (as it were) prior to this draft is to "steal" an option or protocol number from the IANA, just start using it, and hope that it nobody runs into trouble. I don't want to call anyone out specifically, but I suspect that everyone who has had to deal with protocol '0000' (!) or other such oddities has faced knotty interoperability problems. > I think > IPComp (RFC 3173) also took this approach. That's a problem similar to CCP. Anyway, I'd hoped there'd be some sort of general approach here ("when carving out areas of a namespace such that vendors can add undocumented features, the document can advance on standards track when there are independent implementations that gracefully decline to use the extensions; actual successful negotiation of such an option between independent implementations is neither expected nor required") so that we don't push more such drafts out into Informational. But, to move forward, I'm still in favor of calling it Informational. That's sufficient. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Dec 18 10:36:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29478 for ; Thu, 18 Dec 2003 10:36:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F97E912A0; Thu, 18 Dec 2003 10:36:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF40B912A1; Thu, 18 Dec 2003 10:36:40 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ABF4912A0 for ; Thu, 18 Dec 2003 10:36:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7966D5DDDA; Thu, 18 Dec 2003 10:36:39 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 39A7D5DE01 for ; Thu, 18 Dec 2003 10:36:39 -0500 (EST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2003 07:40:22 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBIFabAt018266 for ; Thu, 18 Dec 2003 07:36:37 -0800 (PST) Received: from bray-w2k01.cisco.com (sjc-vpn1-370.cisco.com [10.21.97.114]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOP56666; Thu, 18 Dec 2003 07:36:35 -0800 (PST) Message-Id: <4.3.2.7.2.20031218103555.03bbf900@mira-sjcm-4.cisco.com> X-Sender: bray@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Dec 2003 10:36:35 -0500 To: ietf-ppp@merit.edu From: John Bray Subject: Re: I-D ACTION:draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I just realized I was not subscribed to ietf-ppp-post (I get my IETF mail via an exploder), so this post was filtered out. Resending... John Bray >Date: Fri, 05 Dec 2003 17:26:57 -0500 >To: ernie.tacsik@nokia.com >From: John Bray >Subject: Re: I-D ACTION:draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt >Cc: ietf-ppp@merit.edu > >Please do not do this. This idea was already shot down for IPv4. It is >no more valid for IPv6. > >Please use DHCP. In fact, doesn't RFC 3319 handle this? > >John Bray > >At 03:28 PM 12/5/2003, Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : IPv6CP option for IPv6 SIP Proxy address >> Author(s) : E. Tacsik >> Filename : draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt >> Pages : 11 >> Date : 2003-12-5 >> >>This document defines a new PPP IPCP CONFIGURATION OPTION TYPE for >>returning the addresses of IPv6 SIP proxy server(s). This option >>provides one mechanism that a system may use to locate IPv6 SIP proxy >>server(s). This approach is applicable for a system that is using >>IPv4 over PPP for the link layer protocol and IPv4 address >>allocation. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE >> /internet-drafts/draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >>Content-Type: text/plain >>Content-ID: <2003-12-5150718.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-tacsik-pppext-ipcp-opt-ipv6-sip-proxy-00.txt >> >> From owner-ietf-ppp@merit.edu Thu Dec 18 18:50:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29581 for ; Thu, 18 Dec 2003 18:50:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0E94912B7; Thu, 18 Dec 2003 18:50:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA5F7912B8; Thu, 18 Dec 2003 18:50:23 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73DDC912B7 for ; Thu, 18 Dec 2003 18:50:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6051A5DDD5; Thu, 18 Dec 2003 18:50:21 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 1987A5DDE5 for ; Thu, 18 Dec 2003 18:50:21 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2003 15:53:48 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBINoIZ0012003; Thu, 18 Dec 2003 15:50:18 -0800 (PST) Received: from bray-w2k01.cisco.com (sjc-vpn1-370.cisco.com [10.21.97.114]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOQ12735; Thu, 18 Dec 2003 15:50:16 -0800 (PST) Message-Id: <4.3.2.7.2.20031218173741.03b97fc8@mira-sjcm-4.cisco.com> X-Sender: bray@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Dec 2003 18:49:45 -0500 To: From: John Bray Subject: Re: I-D ACTION:draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt Cc: ietf-ppp@merit.edu In-Reply-To: <200312182030.PAA14972@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I reiterate, the idea of "negotiating" SIP Proxy addresses via IPCP has already been rejected by a clear consensus of the working group (because it duplicates functionality already available via DHCP), and the same reasoning applies to IPv6CP. John Bray At 03:30 PM 12/18/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IPv6CP option for SIP Proxy address > Author(s) : E. Tacsik > Filename : draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt > Pages : 11 > Date : 2003-12-18 > >This document defines a new PPP IPCP CONFIGURATION OPTION TYPE for >returning the addresses of IPv6 SIP proxy server(s). This option >provides one mechanism that a system may use to locate IPv6 SIP proxy >server(s). This approach is applicable for a system that is using >IPv6 over PPP for the link layer protocol and IPv6 address >allocation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE > /internet-drafts/draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-12-18142648.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-tacsik-pppext-ipv6cp-opt-sip-proxy-00.txt > >