Re: [pmtud] Re: [Tsvwg] Working group last call on draft-ietf-tsvwg-sctp-padding-01

"James M. Polk" <jmpolk@cisco.com> Sat, 14 October 2006 05:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYboN-0002xU-R8; Sat, 14 Oct 2006 01:11:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYboM-0002xM-HD; Sat, 14 Oct 2006 01:11:50 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYboL-0007Wy-8a; Sat, 14 Oct 2006 01:11:50 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2006 01:11:49 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9E5Bnv8020408; Sat, 14 Oct 2006 01:11:49 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9E5BmYJ017840; Sat, 14 Oct 2006 01:11:48 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 01:11:48 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.20.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 01:11:48 -0400
Message-Id: <4.3.2.7.2.20061014000643.031bae18@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 14 Oct 2006 00:11:47 -0500
To: Lars Eggert <lars.eggert@netlab.nec.de>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [pmtud] Re: [Tsvwg] Working group last call on draft-ietf-tsvwg-sctp-padding-01
In-Reply-To: <954F2274-CD83-4C1C-B4C2-CF4B520C21D2@netlab.nec.de>
References: <A2CF9A9D-E08B-488B-BAF6-1BB07D720C33@lurchi.franken.de> <451B9B8F.8000607@ericsson.com> <E05CFB40-21C8-4D31-99E8-9BCA43A8C1BD@netlab.nec.de> <A2CF9A9D-E08B-488B-BAF6-1BB07D720C33@lurchi.franken.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 14 Oct 2006 05:11:48.0359 (UTC) FILETIME=[401AC970:01C6EF4F]
DKIM-Signature: a=rsa-sha1; q=dns; l=1878; t=1160802709; x=1161666709; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:Re=3A=20[pmtud]=20Re=3A=20[Tsvwg]=20Working=20group=20last=20call=20on=0 A=20=20draft-ietf-tsvwg-sctp-padding-01 |To:Lars=20Eggert=20<lars.eggert@netlab.nec.de>, =0A=20=20=20=20=20=20=20=20M ichael=20Tuexen=20<Michael.Tuexen@lurchi.franken.de>; X=v=3Dcisco.com=3B=20h=3Dt912MrNCUeXQtaIsb2RpYVxqj6U=3D; b=lNrFyCSCTO5Q/6XSiGXi4/gJOoZmZHzNK27CvgTtDJpgTLxUaRkwCuwt/h7Qxu3H3QVF5owo oq6qkfnXTpl/vF9SR46HHWgoXquS0glrTABIzXg34shurJBae8IqR31L;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Path MTU Discovery WG <pmtud@ietf.org>, tsvwg <tsvwg@ietf.org>
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Errors-To: pmtud-bounces@ietf.org

round 3

At 12:46 PM 10/14/2006 +0900, Lars Eggert wrote:
>On Oct 11, 2006, at 5:57, Michael Tuexen wrote:
>>>Section 5., paragraph 3:
>>> >       The reference to sctp-parameters [3] should be removed
>>>from the
>>> >       "Normative References" section after the IANA section has
>>>been
>>> >       removed.
>>>
>>>   Why would the IANA section be removed?
>>This section is written like the one for SCTP-AUTH which was
>>suggested by
>>James. I thought, that the IANA section gets deleted when IANA has
>>done
>>its job. Isn't that right? James?

I believe stating where in IANA new parameters ought to go is a good thing 
- as it makes their job easier by them not having to guess where it is 
authors had in mind to register something, as I've been told many many 
times as a doc author (Allison trained me well).  There have been many a 
confusing time between IANA folks, ADs, shaephards and authors as to what 
has been intended and what was expected in the old Transport area, 
specifically around SIP, and RSVP vs. COPS parameters.  Writing an IANA 
section that simulates how the new parameters will appear in IANA has 
always gone over well with me (once I learned to do it this way).

I passed this advice along to Michael, and he promptly turned around a 
version of SCTP-AUTH that way (in a day, if I remember correctly).


>The IANA section customarily gets removed when all it has is "this
>document requires no IANA actions", purely to increase readability.
>Documents that require IANA actions do keep the section when published.
>
>The same is true for SCTP-AUTH. I hadn't realized that has the same
>problem and I didn't see an email on the list about this, but the
>IANA section must remain in place there, too.
>
>Lars
>--
>Lars Eggert                                     NEC Network Laboratories
>
>
>
>

_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud