Doug Barton | 1 Mar 03:38 2010
Picon

Re: New version of document for review


On 01/15/10 08:16, Michelle Cotton wrote:
> Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group
> 
> There is a new version of the Internet Assigned Numbers Authority (IANA)
> Procedures for the Management
> of the Transport Protocol Port Number and Service Name Registry document:
> 
> draft-ietf-tsvwg-iana-ports-04.txt
> 
> Please review and send comments.  Your feedback is much appreciated.

I'm writing to provide both review and support of this draft. Before I
do however it's probably useful for me to make some explicit statements,
some of the "should go without saying" variety and some to provide
context for my comments.

I was the General Manager of the IANA from late 2003 through mid 2005.
In that capacity I was proud to manage Michelle as one of my employees.
One of my responsibilities was to oversee the port number allocation
process, including occasionally making the final decisions on these
assignments myself. Other than her public messages regarding these
drafts I have had no communication from Michelle or anyone else from
ICANN regarding this topic. Other than this message today I've not
communicated with them about it. (IOW, ETINC.) I also have experience
with port numbers from the operating system implementer's perspective as
part of a large group of people who have "commit privileges" to the
FreeBSD code base.

With all that out of the way, I would like to commend Michelle and the
(Continue reading)

Fernando Gont | 3 Mar 06:04 2010
Picon

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)

(added CC to tsvwg)

Hello, Alfred,

Thanks so much for your feedback! Comments inline....

> (1)  Fundamental, general issue: Terminology
> 
> A few voices have caused the authors to adopt a rather questionable
> terminology throughout the draft, during its last few revisions.
> 
> - "Randomization" : My 5-vol. Dictionary of Mathematics defines
>    (translated into English):  Randomization; Randomized Algorithm:
>    The introduction of randomness into mathematical algorithms.
>    In practice, pseudo-random numbers are used.
[....]
> 
> I therefore request that these inappropriate changes in terminology be
> backed out again.  "Port number obfuscation" is a serious misnomer;
> port numbers still are transmitted in the clear under the methods
> presented in this draft; so "port number randomization" or, for short,
> "port randomization" is the proper term -- and it is widely adopted
> by the community since several years.

I really don't know how to proceed here. That is, I'd honor your
comment, but clearly that's not just up to me. What do the chairs and
ADs think?

> (2)  Abstract, last sentence
> 
(Continue reading)

James M. Polk | 3 Mar 07:12 2010
Picon

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)

At 11:04 PM 3/2/2010, Fernando Gont wrote:
>(added CC to tsvwg)
>
>Hello, Alfred,
>
>Thanks so much for your feedback! Comments inline....
>
>
> > (1)  Fundamental, general issue: Terminology
> >
> > A few voices have caused the authors to adopt a rather questionable
> > terminology throughout the draft, during its last few revisions.
> >
> > - "Randomization" : My 5-vol. Dictionary of Mathematics defines
> >    (translated into English):  Randomization; Randomized Algorithm:
> >    The introduction of randomness into mathematical algorithms.
> >    In practice, pseudo-random numbers are used.
>[....]
> >
> > I therefore request that these inappropriate changes in terminology be
> > backed out again.  "Port number obfuscation" is a serious misnomer;
> > port numbers still are transmitted in the clear under the methods
> > presented in this draft; so "port number randomization" or, for short,
> > "port randomization" is the proper term -- and it is widely adopted
> > by the community since several years.
>
>I really don't know how to proceed here. That is, I'd honor your
>comment, but clearly that's not just up to me. What do the chairs and
>ADs think?

(Continue reading)

Wei Yongjun | 3 Mar 08:08 2010

Question about SCTP AUTH information structure (SCTP_AUTHINFO)


Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit

Hi all:

The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:

5.2.8.  SCTP AUTH Information Structure (SCTP_AUTHINFO)

   This cmsghdr structure specifies SCTP options for sendmsg().

          +--------------+---------------+----------------------+
          | cmsg_level   | cmsg_type     | cmsg_data[]          |
          +--------------+---------------+----------------------+
          | IPPROTO_SCTP | SCTP_AUTHINFO | struct sctp_authinfo |
          +--------------+---------------+----------------------+

   Here is the definition of the sctp_authinfo structure:

   struct sctp_authinfo {
     uint16_t auth_keyid;
   };

   auth_keyid:  This specifies the shared key identifier used for
      sending the user message.

   An sctp_authinfo item always corresponds to the data in msg_iov.

What is the action when the user DATA chunk be bundled with other
(Continue reading)

Gorry Fairhurst | 3 Mar 10:25 2010
Picon
Picon

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)


I'll just respond on RTP here...

On 03/03/2010 05:04, Fernando Gont wrote:

<snip>

>
>> (2)  Abstract, last sentence
>>
>> The new elaborations on RTP seem to be inappropriate.
>> RTP isn't a "classical" transport protocol.
>> RFC 3550 says (Section 11, 2nd para):
>>
>>   "RTP relies on the underlying protocol(s) to provide demultiplexing of
>>    RTP data and RTCP control streams.  For UDP and similar protocols, ..."
> [...]
>>
>> Therefore, I suggest to drop the clause on RTP entirely:
>
> FWIW, Dan Wing suggested this as one of the possible ways forward for
> the RTP issue. So unless anybody disagrees I will apply your prosed change.
>
>

To me, it would seem OK to see RTP removed from the Abstract.

I would though very much prefer to see it still described in the draft, 
since it is an example of an important transport "layer" that is 
impacted by the methods described in the draft. You may like to think 
(Continue reading)

Internet-Drafts | 3 Mar 20:00 2010
Picon

I-D Action:draft-ietf-tsvwg-ecn-tunnel-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Tunnelling of Explicit Congestion Notification
	Author(s)       : B. Briscoe
	Filename        : draft-ietf-tsvwg-ecn-tunnel-08.txt
	Pages           : 43
	Date            : 2010-03-03

This document redefines how the explicit congestion notification
(ECN) field of the IP header should be constructed on entry to and
exit from any IP in IP tunnel.  On encapsulation it updates RFC3168
to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
ECN processing.  On decapsulation it updates both RFC3168 and RFC4301
to add new behaviours for previously unused combinations of inner and
outer header.  The new rules ensure the ECN field is correctly
propagated across a tunnel whether it is used to signal one or two
severity levels of congestion, whereas before only one severity level
was supported.  Tunnel endpoints can be updated in any order without
affecting pre-existing uses of the ECN field, providing backward
compatibility.  Nonetheless, operators wanting to support two
severity levels (e.g. for pre-congestion notification--PCN) can
require compliance with this new specification.  A thorough analysis
of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need,
RFC4774 gives guidance on designing alternate ECN semantics and this
document extends that to include tunnelling issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-08.txt
(Continue reading)

Gorry Fairhurst | 3 Mar 22:32 2010
Picon
Picon

Comments on draft-ietf-tsvwg-ecn-tunnel-07

Bob, WG,

I've completed a review of the above draft, with a view to starting a 
WGLC. I have some comments, please see below, and have contacted Bob to 
see if he can make a new revision.

Best wishes,

Gorry Fairhurst

----------------------------------------------------------------------------
Issues:

---
1)
634 be followed.  However, alternate ECN tunnelling schemes are NOT
635 RECOMMENDED as the deployment burden of handling exceptional PHBs in

- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is 
not defined in RFC 2119.  If it is intended as a requirements 
expression, it should be rewritten using one of the combinations defined 
in RFC 2119; otherwise it should not be all-uppercase.
- I wonder if this may be written /SHOULD NOT be.../?
---
2)
741 Alarms should be rate-limited so that the anomalous combinations
            ^^^^^^
- Is this a place where the IETF should make a strong requirements 
recommendation, and use /SHOULD/?
---
(Continue reading)

Bob Briscoe | 4 Mar 11:02 2010
Picon

Re: Comments on draft-ietf-tsvwg-ecn-tunnel-07

Gorry,

Thanks for this careful (as always) review.

I've dealt with all your points, responding to 
some where necessary inline. The new draft was 
posted yesterday as draft-ietf-tsvwg-ecn-tunnel-08.

Here's a summary of the changes made as a 
consequence (I omitted to add this text to the 
change log within the doc - if it goes to another draft, I will add it):

 From ietf-07 to ietf-08:

       *  Changes to standards actions:

          +  Section 4: Changed non-RFC2119 phrase 'NOT RECOMMENDED' to
             'SHOULD be avoided', wrt alternate ECN tunnelling schemes.

          +  Section 4.2: Used upper-case in 'Alarms SHOULD be rate-
             limited'.

          +  Section 7: Made bullet #1 in the decapsulation guidelines
             for alternate schemes more precise.  Also changed any upper-
             case keywords in this informative section to lower case.

       *  Editorial changes:

          +  Changed copyright notice to allow for pre-5378 material.

(Continue reading)

Randy Stewart | 5 Mar 13:34 2010
Picon

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

Yongjun-san

I believe when you send with this option you are changing the
key number that you are using. So any new chunks sent at that
point that are auth'd are now using the new key. If each
send specified a different key you would end up with the maybe the last
key as the active one.

At least that is my guess.. Michael?

R
On Mar 2, 2010, at 11:08 PM, Wei Yongjun wrote:

>
> Content-Type: text/plain; charset=GB2312
> Content-Transfer-Encoding: 7bit
>
> Hi all:
>
>
> The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:
>
> 5.2.8.  SCTP AUTH Information Structure (SCTP_AUTHINFO)
>
>   This cmsghdr structure specifies SCTP options for sendmsg().
>
>          +--------------+---------------+----------------------+
>          | cmsg_level   | cmsg_type     | cmsg_data[]          |
>          +--------------+---------------+----------------------+
>          | IPPROTO_SCTP | SCTP_AUTHINFO | struct sctp_authinfo |
(Continue reading)

Michael Tuexen | 5 Mar 13:41 2010
Picon

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

On Mar 5, 2010, at 1:34 PM, Randy Stewart wrote:

> Yongjun-san
> 
> I believe when you send with this option you are changing the
> key number that you are using. So any new chunks sent at that
> point that are auth'd are now using the new key. If each
NO. it only allies to the message you sent down.
> send specified a different key you would end up with the maybe the last
> key as the active one.
> 
> At least that is my guess.. Michael?
When you use the SCTP_AUTHINFO it does only apply to the message
you are currently sending. When you want to change the "default",
you use the SCTP_AUTH_ACTIVE_KEY socket option.

Best regards
Michael
> 
> R
> On Mar 2, 2010, at 11:08 PM, Wei Yongjun wrote:
> 
>> 
>> Content-Type: text/plain; charset=GB2312
>> Content-Transfer-Encoding: 7bit
>> 
>> Hi all:
>> 
>> 
>> The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:
(Continue reading)


Gmane