Lars Eggert | 1 Jul 10:42 2010
Picon

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00

Hi,

On 2010-6-30, at 19:01, ah <at> tr-sys.de wrote:
> Please do not neglect the criticism spelled out repeatedly for
> draft-ietf-tsvwg-iana-ports but rejected by your team.  This
> draft tries to accommodate the restrictions imposed by that memo.
> Yet, to be useful for aligning previous RFCs now deemed non-
> conformant with these rules and recent/ongoing work specifically
> calling for multi-label hierarchical Service Prefixes, this
> draft needs to show a uniform path that can be recommended
> to the authors / WGs where these RFCs are originating from.
> 
> Thus, as a replacement mechanism for specifications using
> Service Prefixes with non-transport protocol Protocol Labels
> and/or more than two labels, the non-normative extension
> mechanism proposed is an essential part of this memo.
> 
> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports
> on the lenght of Service Names and the one-servie-name-per-
> application rule are being relaxed substantially, this extension
> mechanism will remain in this document.

OK, I'm confused. We had a lunch meeting in Anaheim where Olafur was present, and we went down the list of
planned changes to iana-ports to explicitly make sure the two documents are aligned.

If they now are not aligned, there are basically two possibilities: Either we we messed things up when
updating iana-ports, but I at least don't know where we did. Or draft-gudmundsson changed or is planned to
change in ways that are different than what we agreed on.

Can we pencil in a time for a Webex call in order to make progress here?
(Continue reading)

Peter Saint-Andre | 1 Jul 18:52 2010

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00

A point of clarification...

On 6/30/10 4:01 PM, Joe Touch wrote:

> "xmpp" is does not have an Assigned Number, and is not being used 'locally', and
> was never registered with the SRV registry either. Yes, there appear to be a few
> other uses of SRV records other than for the kind of services indicated in the
> IANA ports tale or the SRV registry.

XMPP does have two registered ports (5222 and 5269) but the XMPP WG has
been waiting for the service registry issue to be settled before adding
the appropriate service name registration to the IANA considerations for
draft-ietf-xmpp-3920bis, which is currently in WGLC.

See for instance:

http://www.ietf.org/mail-archive/web/xmpp/current/msg00313.html

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

Attachment (smime.p7s): application/pkcs7-signature, 9 KiB
_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
(Continue reading)

Joe Touch | 1 Jul 19:01 2010
Picon

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00


Peter Saint-Andre wrote:
> A point of clarification...
> 
> On 6/30/10 4:01 PM, Joe Touch wrote:
> 
>> "xmpp" is does not have an Assigned Number, and is not being used 'locally', and
>> was never registered with the SRV registry either. Yes, there appear to be a few
>> other uses of SRV records other than for the kind of services indicated in the
>> IANA ports tale or the SRV registry.
> 
> XMPP does have two registered ports (5222 and 5269)

Agreed - neither is listed as "xmpp", though.

"xmpp-client" and "xmpp-server" are both listed in IANA ports and in the DNS SRV
registry, though.

The point above is about using "xmpp" as the service string.

> but the XMPP WG has
> been waiting for the service registry issue to be settled before adding
> the appropriate service name registration to the IANA considerations for
> draft-ietf-xmpp-3920bis, which is currently in WGLC.
> 
> See for instance:
> 
> http://www.ietf.org/mail-archive/web/xmpp/current/msg00313.html
> 
> Peter
(Continue reading)

Peter Saint-Andre | 1 Jul 19:25 2010

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00

On 7/1/10 11:01 AM, Joe Touch wrote:
> 
> Peter Saint-Andre wrote:
>> A point of clarification...
>>
>> On 6/30/10 4:01 PM, Joe Touch wrote:
>>
>>> "xmpp" is does not have an Assigned Number, and is not being used 'locally', and

Could you clarify what it means to use something "locally"?

>>> was never registered with the SRV registry either. Yes, there appear to be a few
>>> other uses of SRV records other than for the kind of services indicated in the
>>> IANA ports tale or the SRV registry.
>>
>> XMPP does have two registered ports (5222 and 5269)
> 
> Agreed - neither is listed as "xmpp", though.

Correct.

> "xmpp-client" and "xmpp-server" are both listed in IANA ports and in the DNS SRV
> registry, though.
> 
> The point above is about using "xmpp" as the service string.

Is this a reference to the IM and presence SRV label registries called
for by RFC 3861?

http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml
(Continue reading)

Joe Touch | 1 Jul 20:12 2010
Picon

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00


Peter Saint-Andre wrote:
> On 7/1/10 11:01 AM, Joe Touch wrote:
>> Peter Saint-Andre wrote:
>>> A point of clarification...
>>>
>>> On 6/30/10 4:01 PM, Joe Touch wrote:
>>>
>>>> "xmpp" is does not have an Assigned Number, and is not being used 'locally', and
> 
> Could you clarify what it means to use something "locally"?

That's the text RFC 2782; I presume it means "has meaning at the two endpoints,
rather than in an IANA registry".

>>>> was never registered with the SRV registry either. Yes, there appear to be a few
>>>> other uses of SRV records other than for the kind of services indicated in the
>>>> IANA ports tale or the SRV registry.
>>> XMPP does have two registered ports (5222 and 5269)
>>
>> Agreed - neither is listed as "xmpp", though.
> 
> Correct.
> 
>> "xmpp-client" and "xmpp-server" are both listed in IANA ports and in the DNS SRV
>> registry, though.
>>
>> The point above is about using "xmpp" as the service string.
> 
> Is this a reference to the IM and presence SRV label registries called
(Continue reading)

Francois Le Faucheur | 6 Jul 14:32 2010
Picon

Fwd: I-D Action:draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt

James, Subha,

The idea of signaling an RSVP policy locator at the granularity of application class make sense to me.

A few comments on the document from a first read:
	* for GUID, I suggest you use something like "http://www.ietf.org/rfc/rfc4594.txt" instead of "RFC4594"
	* have you considered defining a new attribute (eg APP-SC = Application Service Class) to carry the
application service class instead of reusing the existing APP attribute (that is itended to identify applications)?
	* I strongly suggest you remove the DS Codepoint from the name of each "profile" 
(ie s/The Broadcast video (CS5) Profile/The Broadcast video Profile/) because the relationship between
the two is only "RECOMMENDED". So what you want to signal is the Service Class, which typically will be
mapped into the recommended CS codepoint (but possibly into another).  

Cheers

Francois

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: 5 July 2010 21:30:02 CEST
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt 
> Reply-To: internet-drafts <at> ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams
> 	Author(s)       : J. Polk, S. Dhesikan
> 	Filename        : draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt
(Continue reading)

Gorry Fairhurst | 8 Jul 16:55 2010
Picon
Picon

TSVWG Agenda Requests for IETF-78: THURSDAY, July 29, 2010


TSVWG

This is a call for agenda requests for the upcoming TSVWG session.

We are meeting at 9am local time on THURSDAY, July 29, under the current 
IETF agenda (subject to change).

If you have already asked for a timeslot (see below), you do not need to 
ask again. If, on the other hand, you have not asked for a speaking slot 
(or have "???" against your draft), please do contact us and ask before 
14th June.

Please include the filename of the current ID you wish to present, who 
is going to present, that person's email address, and the amount of time
you/they wish to present.

And finally,

Everything that occurs during and around the the TSVWG session falls 
under  the NOTE WELL as written in RFCs 3978 and 3979.  Please 
understand this when presenting, and talking, in and near the TSVWG 
session room.

Thank you, and see you in about 2 weeks!

Gorry & James
_______________________________________________

Current Requests:
(Continue reading)

James M. Polk | 9 Jul 23:13 2010
Picon

Regarding TSVWG Agenda requests for IETF78

Authors

For anyone wanting presentation time in TSVWG

    - PLEASE send requests to BOTH chairs -

My partner in crime (i.e., my co-chair Gorry) is not going to be 
available for all of the next two weeks, and I can only plan an 
agenda for what I know something about.

James
(with chair hat on)

Internet-Drafts | 12 Jul 18:30 2010
Picon

I-D Action:draft-ietf-tsvwg-sctpsocket-23.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           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-23.txt
	Pages           : 98
	Date            : 2010-07-12

This document describes a mapping of the Stream Control Transmission
Protocol SCTP into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-23.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctpsocket-23.txt): message/external-body, 70 bytes
James M. Polk | 12 Jul 21:00 2010
Picon

New ID on RSVP APP-ID Profiles

TSVWG

(as an individual)

Subha and I have written a new ID based on the RSVP application-ID 
template specified within RFC 2872, to define what field values are 
appropriate to describe several real-time applications (i.e., voice 
and video).  There are 5 voice and video applications described 
within RFC 4594, and a 6th was introduced by RFC 5865.

We simply, in 8 whole pages, define what field values are necessary, 
and what values are to be in each field within the Add-ID template 
for each of these 6 real-time applications. More applications are 
always possible, but we've limited it to these 6 for now.

http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt

The goal of this document is to more effectively communicate what a 
reservation is for, by application type, to allow routers - and 
possibly session border controllers (SBCs) to discover what type of 
application a particular flow is, and apply appropriate treatment to 
that flow - at least in the form of marking the flow with the locally 
appropriate Diffserv codepoint (DSCP).

This document competes with the DCLASS Object defined within RFC 
2996, which only specifies a DSCP value to use, and does not give 
flexibility to each domain - on an end-to-end basis - the ability to 
configure different DSCPs within their domain (i.e., "voice will be 
'101110' only"). We see this as a limitation of what could be.

(Continue reading)


Gmane