Nabble - IETF

ACH configuration use cases

2008-09-05T19:06:26Z

Hi,

One of the outcomes of today's ACH design team call was that we would
ask the BLISS list for use cases that ACH configuration may provide a
solution for so we can extract a requirements document for the
configuration format itself. So, to get the ball rolling, mentioned
today was:

Alice has 2 UA's registered on a single AOR. One is on her desk at
home, the other at work. When she puts her phone at work on DND for
all calls, the DND lamp on her phone at home would automatically
detect this and light up the DND lamp.

and I'd also like to add this case:

Bob has somehow pre-defined 3 different "call profiles": one named "In
a meeting" which will divert all calls to his voice mail account.
Another profile - "At desk" - will accept all incoming calls and send
to any bindings registered against his AOR. finally, the profile
named "Out of the office" will forward all calls to his mobile phone,
sip:bob@.... Any SIP UA that registers against bob's AOR (or
indeed, any 3rd party with sufficient permission - e.g, bob's PA)
should be able to display the currently active profile (for example
"At desk"), as well as provide a list of available profiles, and
change the currently active one.

If you have a use case in mind, please let me know!

Kind regards,

~ Theo
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

From forum: IETF - BLISS

Re: WGLC: draft-ietf-tcpm-tcpsecure-10.txt

2008-09-05T18:38:32Z

On Thu, Aug 21, 2008 at 12:40:43PM -0500, David Borman wrote:

>
> Wes and I would like to start the WG Last Call for:
>
> Title : Improving TCP's Robustness to Blind In-Window
> Attacks'
> Author(s) : A. Ramaiah, R. Stewart & M. Dalal
> Filename : draft-ietf-tcpm-tcpsecure-10.txt
> Pages : 27
> Date : July 9, 2008
> Intended Status : Proposed Standard
>
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt
>
> It is our understanding that all the feedback has been incorporated
> into this latest version and that there are no known outstanding
> issues with this document.
>
> Please send feedback to the list, even if it is just a "yes, go ahead
> and publish".
>
> The WGLC will end on Friday, September 5, 2009.

Overall I think this is a good draft and should advance. I have
comments, which I'll present in page order:

Probably the most technical comment I have is the objection to the
"There was no sound technical reasoning for choosing the Data mitigation
as MAY", which is on P15.

P2:
The 4-tuple is called a socket pair in 793. Even if you don't want to
adopt that terminology, it's probably worth mentioning. I also don't
like "RST, SYN or DATA segment." These are TCP segments with the RST or
SYN flag set and I'd describe them that way. ONce you've had a chance
to define "RST segment" as a segment with the RST bit set, you can use
the short form.

I'd delete "either" from "This can cause the connection to either abort
or possibly cause data corruption." I'd consider deleting "possibly" as
well.

P4:

"The TCP spoofing attacks, which are seen in the Internet today," - I'd
say "The off-path TCP spoofing attacks". We're still describing the
problem, so let's be clear. The next paragraph starts with a
description of the attacks this draft cares about, but until then be
precise.

"... making the odds of guessing correctly the 4-tuple..." I think
"correctly guessing" is more common. I'd actually suggest "... making
it much easier to guess the 4-tuple."

P5:

"One of the important things to note is that, for the attack to succeed
the RST..." -> delete the comma.

"A slight enhancement to the TCP's segment processing" -> delete the
"the".

P6:

"Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack." You mean
"affect" not "effect". I'd also use "drastically affect" rather than
"affect drastically". The order of the adverb is a matter of style,
using "affect" changes the meaning of the sentence to the one you
intend.

On the figures in the "To successfully inject a spoofed packet..."
paragraph:

1. Use parens, not [].
2. Finish the math. If you want to say 1/2 * 2^32 = 2^31 rather than
just dropping 2^31 that's fine, but we're going to be comparing these
requirements, so don't hide the results. "[SITW] shows that the mean
number of tries needed to inject a RST command is (2^31/window) rather
than the 2^31 assumed before."

P7:

"...please refer to draft [RFC4953]" -> "please refer to [RFC4953]"
It's not a draft any more.

P8:

Why use 1) and 2) and A), B), C)? Pick one.

"The previous text, quoted from [RFC0793], woould thus become:" -> That
sounds a lot like we're mandating the change rather than it being a
SHOULD. Do we really need this restatement at all?

P13:

"...so the chances of successfully injecting data into a connection are
1 in (2^32/RCV.WND *2)." In describing the RST attacks, we spoke in
terms of mean number of tries, and I'd be consistent here. Similarly
I'd do the math all the way: " ... so the mean number of tries needed to
inject data successfully is 2*2^32/RWND = 2^33/RCV.WND."

This section used a) and b) instead of either A) and B) or 1) and 2)
(used earlier for the same purpose). Again, pick one.

P15:

"There was no strong technical reasoning for choosing the Data mitigation
as MAY."
First, everywhere else the you use "DATA", I'd use it here.

Second, if I failed to make the case before, let me make it now. The
DATA injection is 4 times less likely than either the RST or the SYN
attacks (2^33 vs 2^31) and may be visible to the application as garbled
data. If the attack is visible an application can gracefully
terminate the connection and re-establish the conversation - unlike the
RST/SYN cases. As the attack is harder to carry out, and a successful
attack may be easier to recover from, I recommend a MAY. I don't care
if you repeat that argument, but I do believe that there are sound
technical reasons for the MAY, and I'd like to see the sentence that
started this comment elided.

P16:

"Currently there is no known bad behavior that can be attributed to the
lack of ACK throttling, but as a general principle, if ever invoked,
something incorrect is occurring and such a mechanism will act as a
failsafe that protects both the sender and the network." -> "While we
have not encountered a case where the lack of ACK throttling can be
exploited, as a fail-safe mechanism we recommend its use. An
implementation may take an excessive number of invocations of the
throttling mechanism as an indication that network conditions are
unusual or hostile."

P18:

"...the middle box design does not comply to [RFC0793]." No middlebox
complies with RFC793; I suggest "...the middle box is generating packets
a conformant TCP endpoint would not generate."

P22:

"ACK throttling was introduced to this document bt combining the
suggestions from the tcpm working group." That seems out of place in
"Contributors". That section is to acknowledge the efforts of
individuals.

P24:

Why are RFC's 4302 and 4303 normative? And if they are why isn't
RFC2385? They're all referred to as possible mitigations. My
preference is making 4302 and 4303 non-normative, but it's very likely
that I'm missing a rule here.

Quotation marks are misplaced on the Medina05 reference.

The NISCC reference lacks a date.

P25:

Quotation marks are misplaced on the SITW reference.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

attachment0 (202 bytes) Download Attachment

From forum: IETF - tcpm

RFC 5337 on Internationalized Delivery Status and Disposition Notifications

2008-09-05T17:07:46Z

A new Request for Comments is now available in online RFC libraries.

RFC 5337

Title: Internationalized Delivery Status and Disposition
Notifications
Author: C. Newman, A. Melnikov, Ed.
Status: Experimental
Date: September 2008
Mailbox: chris.newman@...,
Alexey.Melnikov@...
Pages: 18
Characters: 36324
Updates: RFC3461, RFC3464, RFC3798

I-D Tag: draft-ietf-eai-dsn-06.txt

URL: http://www.rfc-editor.org/rfc/rfc5337.txt

Delivery status notifications (DSNs) are critical to the correct
operation of an email system. However, the existing Draft Standards
(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
in the machine-readable portions of the protocol. This specification
adds a new address type for international email addresses so an
original recipient address with non-US-ASCII characters can be
correctly preserved even after downgrading. This also provides
updated content return media types for delivery status notifications
and message disposition notifications to support use of the new
address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC
3798. This memo defines an Experimental Protocol for the Internet
community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

From forum: IETF - IMA

RFC 5337 on Internationalized Delivery Status and Disposition Notifications

2008-09-05T17:07:46Z

A new Request for Comments is now available in online RFC libraries.

RFC 5337

Title: Internationalized Delivery Status and Disposition
Notifications
Author: C. Newman, A. Melnikov, Ed.
Status: Experimental
Date: September 2008
Mailbox: chris.newman@...,
Alexey.Melnikov@...
Pages: 18
Characters: 36324
Updates: RFC3461, RFC3464, RFC3798

I-D Tag: draft-ietf-eai-dsn-06.txt

URL: http://www.rfc-editor.org/rfc/rfc5337.txt

Delivery status notifications (DSNs) are critical to the correct
operation of an email system. However, the existing Draft Standards
(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
in the machine-readable portions of the protocol. This specification
adds a new address type for international email addresses so an
original recipient address with non-US-ASCII characters can be
correctly preserved even after downgrading. This also provides
updated content return media types for delivery status notifications
and message disposition notifications to support use of the new
address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC
3798. This memo defines an Experimental Protocol for the Internet
community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

RFC 5336 on SMTP Extension for Internationalized Email Addresses

2008-09-05T17:07:43Z

A new Request for Comments is now available in online RFC libraries.

RFC 5336

Title: SMTP Extension for Internationalized Email
Addresses
Author: J. Yao, Ed.,
W. Mao, Ed.
Status: Experimental
Date: September 2008
Mailbox: yaojk@...,
maowei_ietf@...
Pages: 22
Characters: 48110
Updates: RFC2821, RFC2822, RFC4952

I-D Tag: draft-ietf-eai-smtpext-13.txt

URL: http://www.rfc-editor.org/rfc/rfc5336.txt

This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header
information. Communication with systems that do not implement this
specification is specified in another document. This document
updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and
has some material updating RFC 4952This memo defines an Experimental
Protocol for the Internet community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

From forum: IETF - IMA

RFC 5336 on SMTP Extension for Internationalized Email Addresses

2008-09-05T17:07:43Z

A new Request for Comments is now available in online RFC libraries.

RFC 5336

Title: SMTP Extension for Internationalized Email
Addresses
Author: J. Yao, Ed.,
W. Mao, Ed.
Status: Experimental
Date: September 2008
Mailbox: yaojk@...,
maowei_ietf@...
Pages: 22
Characters: 48110
Updates: RFC2821, RFC2822, RFC4952

I-D Tag: draft-ietf-eai-smtpext-13.txt

URL: http://www.rfc-editor.org/rfc/rfc5336.txt

This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header
information. Communication with systems that do not implement this
specification is specified in another document. This document
updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and
has some material updating RFC 4952This memo defines an Experimental
Protocol for the Internet community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

RFC 5335 on Internationalized Email Headers

2008-09-05T17:07:41Z

A new Request for Comments is now available in online RFC libraries.

RFC 5335

Title: Internationalized Email Headers
Author: Y. Abel, Ed.
Status: Experimental
Date: September 2008
Mailbox: abelyang@...
Pages: 14
Characters: 27945
Updates: RFC2045, RFC2822

I-D Tag: draft-ietf-eai-utf8headers-12.txt

URL: http://www.rfc-editor.org/rfc/rfc5335.txt

Full internationalization of electronic mail requires not only the
capabilities to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII
characters in envelope addresses. It also requires being able to
express those addresses and the information based on them in mail
header fields. This document specifies an experimental variant of
Internet mail that permits the use of Unicode encoded in UTF-8,
rather than ASCII, as the base form for Internet email header field.
This form is permitted in transmission only if authorized by an SMTP
extension, as specified in an associated specification. This
specification Updates section 6.4 of RFC 2045 to conform with the
requirements. This memo defines an Experimental Protocol for the Internet
community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

From forum: IETF - IMA

RFC 5335 on Internationalized Email Headers

2008-09-05T17:07:41Z

A new Request for Comments is now available in online RFC libraries.

RFC 5335

Title: Internationalized Email Headers
Author: Y. Abel, Ed.
Status: Experimental
Date: September 2008
Mailbox: abelyang@...
Pages: 14
Characters: 27945
Updates: RFC2045, RFC2822

I-D Tag: draft-ietf-eai-utf8headers-12.txt

URL: http://www.rfc-editor.org/rfc/rfc5335.txt

Full internationalization of electronic mail requires not only the
capabilities to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII
characters in envelope addresses. It also requires being able to
express those addresses and the information based on them in mail
header fields. This document specifies an experimental variant of
Internet mail that permits the use of Unicode encoded in UTF-8,
rather than ASCII, as the base form for Internet email header field.
This form is permitted in transmission only if authorized by an SMTP
extension, as specified in an associated specification. This
specification Updates section 6.4 of RFC 2045 to conform with the
requirements. This memo defines an Experimental Protocol for the Internet
community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community. It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@.... Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

Update on the Mail List Issue

2008-09-05T16:12:38Z

I want to give everyone an update on what recently took place with the IETF
mail lists.

Several months ago Henrik wrote a new program to replace TMDA (which was
functioning until that time as the IETF spam protection mechanism). TMDA was
very inefficient and those inefficiencies led to server crashes whenever a
heavy spam run was made at the system.

At any rate, postconfirm has been functioning quite nicely until now --
thank you Henrik! -- but, as is the case with all new pieces of software, a
bug appeared.

The email delivery process generally works like this: email is sent to our
servers. The mail then goes to postconfirm so that it can be verified as
legitimate. If it is spam, the email dies there. Legitimate email is sent to
the mailman list servers -- Mailman is program the IETF currently uses for
email -- for processing.

Unfortunately, yesterday after a server reboot, the postconfirm program
failed to restart. During the time that mail was lost, IETF mail transport
was up and it was passing email to postconfirm. But because postconfirm was
jammed, it reacted by throwing the mail away (rather than holding it and
retrying it later). Mailman, which was up and running, didn't receive any
list messages. And because of where the problem was, no one who sent a
message to the list would have receive a bounce message -- the message just
disappeared.

However, a little while ago Henrik located the source of the problem in
postonfirm and believes that he has repaired it. We also determined why
postconfirm didn't restart after the server reboot, and we've corrected for
that as well. Finally, we've assigned a watchdog program to postconfirm so
that if it ever crashes in the future, the server will start it again and
notify us that there is an issue.

While we believe everything to be resolved now, we appreciate your patience
as we continue to work to address any issues that may appear. And a big
thank you goes to Henrik, who just spent his Friday night working to repair
this problem.

Alexa

_______________________________________________
Ietf mailing list
Ietf@...
https://www.ietf.org/mailman/listinfo/ietf

From forum: IETF - IETF

Update on the Mail List Issue

2008-09-05T16:12:38Z

I want to give everyone an update on what recently took place with the IETF
mail lists.

Several months ago Henrik wrote a new program to replace TMDA (which was
functioning until that time as the IETF spam protection mechanism). TMDA was
very inefficient and those inefficiencies led to server crashes whenever a
heavy spam run was made at the system.

At any rate, postconfirm has been functioning quite nicely until now --
thank you Henrik! -- but, as is the case with all new pieces of software, a
bug appeared.

The email delivery process generally works like this: email is sent to our
servers. The mail then goes to postconfirm so that it can be verified as
legitimate. If it is spam, the email dies there. Legitimate email is sent to
the mailman list servers -- Mailman is program the IETF currently uses for
email -- for processing.

Unfortunately, yesterday after a server reboot, the postconfirm program
failed to restart. During the time that mail was lost, IETF mail transport
was up and it was passing email to postconfirm. But because postconfirm was
jammed, it reacted by throwing the mail away (rather than holding it and
retrying it later). Mailman, which was up and running, didn't receive any
list messages. And because of where the problem was, no one who sent a
message to the list would have receive a bounce message -- the message just
disappeared.

However, a little while ago Henrik located the source of the problem in
postonfirm and believes that he has repaired it. We also determined why
postconfirm didn't restart after the server reboot, and we've corrected for
that as well. Finally, we've assigned a watchdog program to postconfirm so
that if it ever crashes in the future, the server will start it again and
notify us that there is an issue.

While we believe everything to be resolved now, we appreciate your patience
as we continue to work to address any issues that may appear. And a big
thank you goes to Henrik, who just spent his Friday night working to repair
this problem.

Alexa

_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

Fwd: I-D Action:draft-rescorla-tls-suiteb-03.txt

2008-09-05T16:08:17Z

I thought that people on this mail list would be interested in this
Internet-Draft.

Russ

>From: Internet-Drafts@...
>To: i-d-announce@...
>Subject: I-D Action:draft-rescorla-tls-suiteb-03.txt
>Date: Fri, 5 Sep 2008 14:15:01 -0700 (PDT)
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
> Title : Suite B Cipher Suites for TLS
> Author(s) : M. Salter, et al.
> Filename : draft-rescorla-tls-suiteb-03.txt
> Pages : 9
> Date : 2008-09-05
>
>The United States Government has published guidelines for "NSA Suite
>B Cryptography," which defines cryptographic algorithm polcy for
>national security applications. This document defines a profile of
>TLS which is conformant with Suite B.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-03.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.

_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls

From forum: IETF - TLS

I-D Action:draft-ietf-nfsv4-minorversion1-26.txt

2008-09-05T15:45:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

Title : NFS Version 4 Minor Version 1
Author(s) : S. Shepler, et al.
Filename : draft-ietf-nfsv4-minorversion1-26.txt
Pages : 605
Date : 2008-09-05

This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS
version 4 minor version one include: Sessions, Directory Delegations,
and parallel NFS (pNFS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-26.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.

_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4

draft-ietf-nfsv4-minorversion1-26.txt (73 bytes) Download Attachment

From forum: IETF - nfsv4

I-D Action:draft-ietf-nfsv4-minorversion1-dot-x-09.txt

2008-09-05T15:45:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

Title : NFSv4 Minor Version 1 XDR Description
Author(s) : S. Shepler, et al.
Filename : draft-ietf-nfsv4-minorversion1-dot-x-09.txt
Pages : 72
Date : 2008-09-05

This Internet-Draft provides the XDR description for NFSv4 minor
version one.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-09.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.

_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4

draft-ietf-nfsv4-minorversion1-dot-x-09.txt (73 bytes) Download Attachment

From forum: IETF - nfsv4

I-D Action:draft-ietf-nfsv4-minorversion1-26.txt

2008-09-05T15:45:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

Title : NFS Version 4 Minor Version 1
Author(s) : S. Shepler, et al.
Filename : draft-ietf-nfsv4-minorversion1-26.txt
Pages : 605
Date : 2008-09-05

This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS
version 4 minor version one include: Sessions, Directory Delegations,
and parallel NFS (pNFS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-26.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.

_______________________________________________
I-D-Announce mailing list
I-D-Announce@...
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

draft-ietf-nfsv4-minorversion1-26.txt (73 bytes) Download Attachment

From forum: IETF - I-D-Announce

I-D Action:draft-ietf-nfsv4-minorversion1-dot-x-09.txt

2008-09-05T15:45:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

Title : NFSv4 Minor Version 1 XDR Description
Author(s) : S. Shepler, et al.
Filename : draft-ietf-nfsv4-minorversion1-dot-x-09.txt
Pages : 72
Date : 2008-09-05

This Internet-Draft provides the XDR description for NFSv4 minor
version one.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-09.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.

_______________________________________________
I-D-Announce mailing list
I-D-Announce@...
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

draft-ietf-nfsv4-minorversion1-dot-x-09.txt (73 bytes) Download Attachment

From forum: IETF - I-D-Announce

Re: Format of IPv4/IPv6 addresses in fs_locations / fs_locations_info

2008-09-05T15:41:41Z

draft-26 of NFSv4.1 now specifies the below.

On Fri, August 22, 2008 11:06 am, Spencer Shepler wrote:

>
> On Aug 22, 2008, at 1:02 PM, Mike Eisler wrote:
>
>>
>> Since this is underspecified, we need to be very forgiving.
>
> Sure. I don't have any problem with what is below.
>
> Spencer
>
>>
>>
>>>> My working assumption/intent has been Universal address. This
>>>> allows
>>
>> There is no netid though. The NFSv4.0 and 4.1 specifications
>> only allow IPv4 and IPv6. In addition, the specifications do not
>> mention the port part of the address.
>>
>> So I think that clients have to be able to deal with:
>>
>> h1.h2.h3.h4 - an IPv4 address assumed to listen on port 2049
>> h1.h2.h3.h4.p1.p2 - an IPv4 address assume to listen on port
>> p2*256+p1.
>>
>> x1:x2:x3:x4:x5:x6:x7:x8 - an IPv6 assumed to listen on port 2049
>> x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 - an IPv6 assumed to listen on port
>> p2*256+p1
>>
>> Also there are bunches of short representations for x1:...x6,
>> which
>> http://tools.ietf.org/html/draft-ietf-nfsv4-rpc-netid-03#section-3.2.3.4
>> alludes to, and makes a reference to RFC (Section 2.2) 4291.
>>
>>
>>
>> On Fri, August 22, 2008 6:17 am, Spencer Shepler wrote:
>>>
>>> On Aug 21, 2008, at 4:14 PM, Trond Myklebust wrote:
>>>
>>>> Hi,
>>>>
>>>> RFC3530 and the draft NFSv4.1 spec both state that the server
>>>> addresses
>>>> supplied in fs_locations and fs_locations_info may be either DNS
>>>> names,
>>>> or as 'literal IP addresses'.
>>>>
>>>> My question is then, what is a 'literal IP address'? Is it another
>>>> instance of a 'universal address' as defined in section 2.2 of
>>>> RFC2373,
>>>> or is it something else? If so, what is the definition?
>>>
>>> My working assumption/intent has been Universal address. This allows
>>> for port
>>> redirection as well as IP address redirection and relies on a
>>> definition that is used
>>> within the spec already.
>>>
>>> Spencer
>>>
>>>>
>>>>
>>>> Cheers
>>>> Trond
>>>>
>>>>
>>>> From: "J. Bruce Fields" <bfields@...>
>>>> Date: August 21, 2008 3:46:20 PM CDT
>>>> To: chucklever@...
>>>> Cc: linux-nfs@...
>>>> Subject: Re: [PATCH] nfs: Fix misparsing of nfsv4 fs_locations
>>>> attribute
>>>>
>>>>
>>>> On Wed, Aug 20, 2008 at 10:00:25PM -0400, Chuck Lever wrote:
>>>>> On Wed, Aug 20, 2008 at 7:30 PM, J. Bruce Fields
>>>>> <bfields@...
>>>>>> wrote:
>>>>>> On Wed, Aug 20, 2008 at 06:07:50PM -0400, Chuck Lever wrote:
>>>>>>> What may be confusing you is that scope delimiters are used
>>>>>>> almost
>>>>>>> exclusively for link-local addresses, which are valid only on the
>>>>>>> local host.
>>>>>>>
>>>>>>> If you don't want to handle a referral that uses a link-local
>>>>>>> address,
>>>>>>> or you don't want to handle a link-local address with a scope ID,
>>>>>>> then
>>>>>>> there are explicit checks you can do.
>>>>>>
>>>>>> Well, the current code does allow a referral to point to
>>>>>> 127.0.0.1. I
>>>>>> don't know what to think of that; it seems unlikely to be useful
>>>>>> for
>>>>>> anything but testing, and possibly succeptible to abuse, but of
>>>>>> course
>>>>>> the protocol doesn't forbid it.
>>>>>
>>>>> Link-local is not the same as loopback.
>>>>>
>>>>> A link-local address is an address that is constructed by a
>>>>> standards-defined method for each active NIC on a host. It is
>>>>> not a
>>>>> route-able address, so it's good only for the local subnet. It's a
>>>>> method by which network service is exposed to higher levels in the
>>>>> network layer without having to use an external service like DHCP.
>>>>> It's a bootstrap address, more or less.
>>>>>
>>>>>> I google around a bit, but still don't get the scope stuff. Are
>>>>>> they
>>>>>> really part of an "ipv6 address"? I thought an ipv6 address was
>>>>>> just a
>>>>>> 128-bit number? (Or do they just give another way of writing
>>>>>> something
>>>>>> that you could already write without the %?)
>>>>>
>>>>> Unfortunately good IPv6 documentation is pretty hard to find.
>>>>> There
>>>>> are a lot of RFCs that specify just a little corner of IPv6 (and
>>>>> even
>>>>> those usually have corrections or amendments in later RFCs), so
>>>>> it's
>>>>> difficult to know where to begin. IPv6 is nearly a complete
>>>>> reconception of the internet, so many IPv4 concepts simply don't
>>>>> translate. I don't think there's anything equivalent to a scope
>>>>> delimiter in IPv4. The following is my understanding of how this
>>>>> works.
>>>>>
>>>>> This is really a question of how to map a presentation format
>>>>> address
>>>>> (a string that represents the numeric form of the address, like
>>>>> dotted-quad notation) to a sockaddr.
>>>>
>>>> OK, but what the v4 rfc says isn't that the fs_location field can
>>>> contain any representation of a sockaddr; it says that it can
>>>> contain "a
>>>> traditional DNS host name, IPv4 address, or IPv6 address."
>>>>
>>>> Every definition of "IPv6 address" I can find says that it's just
>>>> the
>>>> 128 bits you put in sin6_addr. The scope id field, like a port
>>>> number,
>>>> is something in addition.
>>>>
>>>> So if we see such a string we should just assume it's garbage.
>>>>
>>>>> The sockaddr_sin6 structure has a field for the scope ID,
>>>>> sin6_scope_id. The % delimits the host address from a string that
>>>>> identifies a local NIC. You can specify a device name, like
>>>>> "eth0,"
>>>>> or a number, which means the same thing. The number is referred to
>>>>> as
>>>>> an interface index, or a scope ID. The device name is converted
>>>>> by a
>>>>> locally-defined mechanism to a scope ID (the numeric equivalent)
>>>>> and
>>>>> stored in the sin6_scope_id field of a sockaddr_sin6.
>>>>>
>>>>> Link-local addresses require a specific NIC to be identified to
>>>>> work
>>>>> properly, even if there is only a single NIC on the host, since the
>>>>> "lo" virtual interface also has an interface index. You can also
>>>>> use
>>>>> a scope ID with a non-link-local address to force which NIC is
>>>>> used.
>>>>> By and large, these interface indices are not meaningful anywhere
>>>>> but
>>>>> on the host that has that link-local address assigned to one of its
>>>>> NICs.
>>>>
>>>> OK, so that definitely doesn't sound like something that makes sense
>>>> outside the client.
>>>>
>>>>> It really depends on how the referral hostname string is generated,
>>>>> but I would say that whatever follows the % should be ignored, or
>>>>> you
>>>>> could generate a warning or error.
>>>>
>>>> So I think we should be harsher and just not attempt to parse a
>>>> string
>>>> that looks like this at all.
>>>>
>>>> --b.
>>>>
>>>>> You can let the existing super.c
>>>>> address parser handle the '%' and check to see if sin6_scope_id is
>>>>> non-zero on return (or just zero it unconditionally if you want to
>>>>> ignore these altogether). If the NFSv4 standard doesn't say
>>>>> anything
>>>>> about IPv6 interface IDs, then I suppose we are free to treat this
>>>>> any
>>>>> way we think is reasonable.
>>>>>
>>>>> I'm still not quite sure how to handle link-local addresses for
>>>>> NFSv4
>>>>> callback, for example. Generally it doesn't make sense to hand the
>>>>> server an interface ID that is valid only on the client, so
>>>>> mount.nfs
>>>>> just strips the interface ID when generating the callback IP
>>>>> address
>>>>> string: it won't pass a scope-delimited presentation format address
>>>>> in
>>>>> the clientaddr= option.
>>>>>
>>>>> For a link-local callback address, the server then must determine
>>>>> which of its own interfaces it must use to contact the client via
>>>>> that
>>>>> link-local address, and append it via a % or by setting the
>>>>> sin6_scope_id field. Or it can simply decide not to call a client
>>>>> back that passed it a link-local address as a callback address.
>>>>>
>>>>> --
>>>>> Chuck Lever
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>>>> in
>>>> the body of a message to majordomo@...
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>> _______________________________________________
>>>> nfsv4 mailing list
>>>> nfsv4@...
>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@...
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>>
>> --
>> Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
>> http://blogs.netapp.com/eislers_nfs_blog/
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@...
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@...
> https://www.ietf.org/mailman/listinfo/nfsv4
>

--
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4

From forum: IETF - nfsv4

Re: SDP Negotiation based on Profile-Level-Id

2008-09-05T15:37:16Z

Randell,
I think that sprop-parameter-sets include the parameter sets that will be
used by the encoder and not what it can receive, sprop parameters are not
used for negotiation. The only requirement is that the receiver will have
the parameter sets before they are used. It is true that the parameter-add
parameter got me confused and I am not sure why it is there in the first
place. I think that the only limitation should be that the added parameter
sets can not contradict the mode (profile-level and other receive
parameters) that the offer can receive.
Since we are adding text about in-band parameter sets than we probably need
to clarify the parameter-add usage.
I think that we need to clarify that if the offer offers for example level 3
with parameter sets for level 3 and the answer can only receive 2.1 than the
offerer needs to send 2.1 and MUST provide relevant parameter sets either as
sprop-parameter sets or inband so that they should be available to the
receiver before they are used.

Some text from RFC 3984

Section 8
Some parameters provide a receiver with the properties of the stream
that will be sent. The name of all these parameters starts with
"sprop" for stream properties. Some of these "sprop" parameters are
limited by other payload or codec configuration parameters. For
example, the sprop-parameter-sets parameter is constrained by the
profile-level-id parameter. The media sender selects all "sprop"
parameters rather than the receiver. This uncommon characteristic of
the "sprop" parameters may not be compatible with some signaling
protocol concepts, in which case the use of these parameters SHOULD
be avoided.

And

sprop-parameter-sets:
This parameter MAY be used to convey
any sequence and picture parameter set NAL
units (herein referred to as the initial
parameter set NAL units) that MUST precede any
other NAL units in decoding order. The
parameter MUST NOT be used to indicate codec
capability in any capability exchange
procedure.

I noticed the text

"The "sprop-parameter-sets" parameter is used as described above.
In addition, an answerer MUST maintain all parameter sets received
in the offer in its answer. Depending on the value of the
"parameter-add" parameter, different rules apply: If "parameter-
add" is false (0), the answer MUST NOT add any additional
parameter sets. If "parameter-add" is true (1), the answerer, in
its answer, MAY add additional parameter sets to the "sprop-
parameter-sets" parameter. The answerer MUST also, independent of
the value of "parameter-add", accept to receive a video stream
using the sprop-parameter-sets it declared in the answer.

Informative note: care must be taken when parameter sets are
added not to cause overwriting of already transmitted parameter
sets by using conflicting parameter set identifiers."

But after you see

Furthermore, the following considerations are necessary:

o Parameters used for declaring receiver capabilities are in general
downgradable; i.e., they express the upper limit for a sender's
possible behavior. Thus a sender MAY select to set its encoder
using only lower/lesser or equal values of these parameters.
"sprop-parameter-sets" MUST NOT be used in a sender's declaration
of its capabilities, as the limits of the values that are carried
inside the parameter sets are implicit with the profile and level
used.

The text in example 8.3

As the Offer/Answer negotiation covers both sending and receiving
streams, an offer indicates the exact parameters for what the offerer
is willing to receive, whereas the answer indicates the same for what
the answerer accepts to receive. In this case the offerer declared
that it is willing to receive payload type 98. The answerer accepts
this by declaring a equivalent payload type 97; i.e., it has
identical values for the three parameters "profile-level-id",
packetization-mode, and "sprop-deint-buf-req". This has the
following implications for both the offerer and the answerer
concerning the parameters that declare properties. The offerer
initially declared a certain value of the "sprop-parameter-sets" in
the payload definition for PT=98. However, as the answerer accepted
this as PT=97, the values of "sprop-parameter-sets" in PT=98 must now
be used instead when the offerer sends PT=97. Similarly, when the
answerer sends PT=98 to the offerer, it has to use the properties
parameters it declared in PT=97.

Demonstrate that the parameter sets are for the send side and not the
receive side.

Roni

-----Original Message-----
From: Randell Jesup [mailto:rjesup@...]
Sent: Friday, September 05, 2008 6:51 PM
To: Roni Even
Cc: 'sunil.kumar'; 'Tom Taylor'; 'IETF AVT WG'
Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

"Roni Even" <ron.even.tlv@...> writes:
>What do you mean by "For example, level downgrade fails or is very
>painful when used with the (recommended) sprop-parameter-sets parameter"

Witness the discussions at IETF 70(?) in Philadelphia on the topic.

Note that parameter sets include a copy of the profile-level-id values,
so you have to use a parameter set that matches the profile-level-id
agreed to (or one you know the answerer can decode, which means a lower
level with the same constraints).

Without sprop-parameter-sets, it's not too hard (see the example I gave -
if you want to handle an answer with different constraints it causes a
small payload explosion, but not too bad). You send parameter sets
in-band, and can choose them to match the result of negotiation. This
works, with some downsides especially on packet loss at stream start, and
wastes some bandwidth (especially in mode 0).

With sprop-parameter-sets, in order to have a level-downgrade in the
response, you have problems. For example, the answerer is *required* to
include the parameter sets from the offer in the answer ("an answerer MUST
maintain all parameter sets received in the offer in its answer"). The
answer can add parameter sets (usually), so it could *add* a parameter set
for the lower level in the response, and then send data using that
parameter set. However, unless the offerer had included a parameter set
for the exact level (or lower) that the answerer selected, the offerer
can't send any video to the answerer (since it has to use a parameter set
from the original offer) - or it could send in-band parameter sets (that
don't conflict with the parameter sets it already offered), which steps on
the whole reason for handling them in the negotiation. The alternative is
for the offerer to include parameter sets for *every* possible level
downgrade (ugh), or include one or two lower-level ones, and on a level
downgrade drop the first one lower than the answer.

It gets even more complex with the "matching" rules for payloads.

Ugh.

Of course, no one appears to implement sprop-parameter-sets per the spec
anyways. (We come close, but with a bunch of kludges to try to get it to
work with people who ignore sprop-parameter-sets (almost everyone) or get
it wrong.) And we don't handle level-downgrade for sprop-parameter-sets.

Randell wrote:

>Correct, though there was a "clarification" posted (by Magnus and others)
>after 3984 that said that the level part could be downgraded in a response.
>However, in trying to actually write that into 3984bis, it's clear that
>the "clarification" has major problems in practice without additional
>guidance and mechanisms. (For example, level downgrade fails or is very
>painful when used with the (recommended) sprop-parameter-sets parameter.)
>
>>This topic was discussed and the 3984bis draft will fix it to recognize
>that
>>the level part does not have to be symmetrical.
>
>Or rather, we still hope the 3984bis draft will find a way to fix that.
>So far, it does not have a usable overall fix (IMHO).
>
>>Roni Even
>>
>>-----Original Message-----
>>
>>Sunil writes:
>>> When we tried to make Video call from Polycom to Eyebeam (and vice
>>> versa), video negotiation got failed.
>>> Eyebeam supports H.264(Profile Level Id = 42e015).
>>> Polycom supports H.264(Profile Level Id = 42a014).
>>>
>>> As per RFC 3984(Page 38)
>>> ****************************************************
>>> If the profile-level-id parameter is used for
>>> capability exchange or session setup procedure,
>>> it indicates the profile that the codec
>>> supports and the highest level
>>> supported for the signaled profile.
>>> ****************************************************
>>> Call from Polycom to Eyebeam:
>>> Eyebeam supports Level 2.1(42e015) and it should be able to handle
>>> 2.0(42a014) level.But it rejects the Video Offer.
>>>
>>> Could any one help us to understand to do SDP Codec negotiation based
>>> on the Profile-Level-Id?
>
>Another major problem is that pretty much NO ONE properly and fully
>implements RFC 3984.
>
>In the case of Polycom to Eyebeam, Eyebeam *should* be able to realize it
>could respond with level 2.0 - however, the offer also specifies "a0" for
>constraints, while Eyebeam naturally supports "e0". Since polycom asked
>for less constraints ("constraint bit 1" isn't set), it's possible that
>Eyebeam can't handle it (can't use 42a014, though it should be able to
>handle 42e014), and so rejects it. You're never allowed to change
>constraints in the answer, even in 3984bis.
>
>The upshot of all this is that, once again, for wide compatibility a device
>has to offer almost every possible combination of settings in the offer if
>you want to follow 3984. For example, Polycom *could* offer:
>m=video 2345 RTP/AVP 90 91 92 93 94 95
>...
>a=fmtp:90 profile-level-id=42a014;packetization-mode=0;...
>a=fmtp:91 profile-level-id=42a014;packetization-mode=1;...
>a=fmtp:92 profile-level-id=42e014;packetization-mode=0;...
>a=fmtp:93 profile-level-id=42e014;packetization-mode=1;...
>a=fmtp:94 profile-level-id=428014;packetization-mode=0;...
>a=fmtp:95 profile-level-id=428014;packetization-mode=1;...
>
>And if you include sprop-parameter-sets, you have to include parameter-sets
>for every possible level downgrade as well in the response. If you don't
>allow downgrade, you have to include separate payloads for each possible
>level downgrade (times each possible packetization-mode).

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team
rjesup@...
"The fetters imposed on liberty at home have ever been forged out of the
weapons
provided for defence against real, pretended, or imaginary dangers from
abroad."
- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

From forum: IETF - avt