Nabble - IETF

Re: Adding a spam button to MUAs

2009-12-22T17:53:00Z

>I think the problem is that if you open it up to more than one bit, it
>begs the question of what the actual number of bits such a button is.

ARF has a bunch of options added at the request of ESPs intended to
support multiple buttons, e.g., spam, opt-out from this list, opt-out
from everything, etc.

As far as I can tell, the only ones that have ever been used are spam
and virus, the latter done mechanically when the message has the bit
pattern of an executable.

Most people have only the dimmest understanding of opt-in, opt-out,
what they subscribed to, etc. There are a lot of obvious analogies to
paper mail and such that are totally misleading, but close enough to
confuse people. One button is plenty.

I also think that most of the useful info from multiple buttons could
be extracted mechanically from the mail stream, e.g., if the sender has
sent multiple messages before and it has a List-Unsubscribe: header,
it's probably an opt-out, not a spam complaint.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

From forum: IETF - Asrg

I-D Action:draft-yao-dnsext-bname-00.txt

2009-12-22T17:45:02Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Bundle DNS Name Redirection
Author(s) : J. Yao, et al.
Filename : draft-yao-dnsext-bname-00.txt
Pages : 12
Date : 2009-12-22

This document defines a new DNS Resource Record called "BNAME", which
provides the capability to map an entire tree of the DNS name space
to another domain. It differs from the CNAME record which maps a
single node of the name space, from the DNAME which maps the subtree
of the DNS name space to another domain.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 6, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yao-dnsext-bname-00.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-yao-dnsext-bname-00.txt (73 bytes) Download Attachment

From forum: IETF - I-D-Announce

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T16:52:33Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mahdavi, Jamshid wrote:
> As it happens, we don't modify options at all. What our boxes do is
> terminate one TCP connection (essentially masquerading as the server),
> and then create a new connection to the server (with whatever new
> options we choose) and optionally masquerade as the client on that
> connection (commonly known as ip-spoofing).

Masquerading is not standards track. You're not only asking for an
experimental RFC, you're asking us to allow masquerading.

...
> So, in my view, our draft does not propose to either allow or
> disallow "modification" of TCP options. Instead, we define a new
> option which may be used by devices that originate connections
> (either clients or proxies), or by devices which are already in the
> business of twiddling with existing connections.

You're defining an option that is only useful by a box that violates
existing standards - whether they already do so or not, that causes a
problem AFAICT for TCPM to take this on as a WG item.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:touch@...]
> Sent: Tue 12/22/2009 4:22 PM
> To: Mahdavi, Jamshid
> Cc: tcpm@...
> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
>
>
>
> Mahdavi, Jamshid wrote:
> ...
>> I might be putting some words into Joe's mouth here, but it sounded
>> like you would be ok with adopting the general problem of middlebox
>> discovery as a WG item, but not necessarily starting from the solution
>> that we have proposed. I think that if we actually need to go back to
>> starting at square one we could do that, although you'll understand why
>> we'd prefer not to.
>
> I want to start with understanding the problem and why it has to be
> solved with TCP options in devices that aren't supposed to be modifying
> a TCP header (as opposed to IP options in those packets).
>
> If this were to move forward, we'd need to understand how many current
> Internet standards are updated by allowing intermediate devices to
> modify TCP headers.
>
> I don't see a huge problem if these issues are addressed using the
> current solution, e.g., moving forward as suggested by Wes. However, if
> these cannot be sufficiently addressed, I hope we can accept a solution
> that is compatible with the architecture (whether modified or completely
> different - I'm not suggesting I know which is the case, though) - not
> just the one that happens to be deployed.
>
> A key question is whether this qualifies as a minor modification of TCP,
> or whether this ought to be in the TSVWG. IMO, adding an option is
> minor, but changing the standards to allow middleboxes to modify options
> is major.
>
> Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
=3xz3
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

From forum: IETF - tcpm

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T16:44:30Z

As it happens, we don't modify options at all. What our boxes do is terminate one TCP connection (essentially masquerading as the server), and then create a new connection to the server (with whatever new options we choose) and optionally masquerade as the client on that connection (commonly known as ip-spoofing).

Not all middleboxes work this way, of course. NATs are an obvious example where connections are not terminated. Boxes like that may (I believe) modify options, perhaps by removing ones they don't know about. We see this sort of thing from time to time. Even outside of what we are doing for discovery, we also rely on options for things like TCP large windows support so it is something we watch for.

So, in my view, our draft does not propose to either allow or disallow "modification" of TCP options. Instead, we define a new option which may be used by devices that originate connections (either clients or proxies), or by devices which are already in the business of twiddling with existing connections.

--J

-----Original Message-----
From: Joe Touch [mailto:touch@...]
Sent: Tue 12/22/2009 4:22 PM
To: Mahdavi, Jamshid
Cc: tcpm@...
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mahdavi, Jamshid wrote:
...
> I might be putting some words into Joe's mouth here, but it sounded
> like you would be ok with adopting the general problem of middlebox
> discovery as a WG item, but not necessarily starting from the solution
> that we have proposed. I think that if we actually need to go back to
> starting at square one we could do that, although you'll understand why
> we'd prefer not to.

I want to start with understanding the problem and why it has to be
solved with TCP options in devices that aren't supposed to be modifying
a TCP header (as opposed to IP options in those packets).

If this were to move forward, we'd need to understand how many current
Internet standards are updated by allowing intermediate devices to
modify TCP headers.

I don't see a huge problem if these issues are addressed using the
current solution, e.g., moving forward as suggested by Wes. However, if
these cannot be sufficiently addressed, I hope we can accept a solution
that is compatible with the architecture (whether modified or completely
different - I'm not suggesting I know which is the case, though) - not
just the one that happens to be deployed.

A key question is whether this qualifies as a minor modification of TCP,
or whether this ought to be in the TSVWG. IMO, adding an option is
minor, but changing the standards to allow middleboxes to modify options
is major.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxYroACgkQE5f5cImnZrsrbQCgghukQhjWuxbhIAOYaMldsLN4
A1kAoIknMDXflTxPUx2Vyeua4xsoOk0C
=TPlf
-----END PGP SIGNATURE-----

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

From forum: IETF - tcpm

Re: Updated TLSTM document

2009-12-22T16:41:07Z

>>>>> On Fri, 18 Dec 2009 18:16:53 +0100, "tom.petch" <cfinss@...> said:

tp> I find this a bit light still on client side processing of certs.

I've tried to careful walk the line of too much vs too little (in fact,
I've recently removed some DTLS specific handling and have moved a lot
of text to an appendix because WG members thought there was too much
detail). In short, it's not our job to specify how to process
certificates as that's already documented in other documents like 5280.

tp> The I-D rightly says that the use of certs by TLS is optional for
tp> both client and server.

True, but it also says that this document is only specifying X.509 based
authentication of clients and servers. It doesn't preclude other forms
of TLS usage, but is only concentrating on the X.509 usage.

tp> What it does not say is that many, if not most, uses of TLS require
tp> server certs and not client certs - some stacks would even appear to
tp> fail when client certs are involved.

Most web uses do, yes. I have a number of personal client-side
certificates that disagree with your statement that they're not commonly
used. Their usage has definitely been increasing in the past decade,
though not as much over port 80 which is where many people believe all
TLS takes place.

tp> As I see, it is the client cert that here is the basis for the
tp> derivation of the securityName and so is REQUIRED. How
tp> do you ensure that a client Cert is even sent?

You'll get an error if you follow the Elements of Procedure without a
client offering a certificate. Specifically:

If any verification fails in any way (for example because of
failures in cryptographic verification or because of the lack
of an appropriate row in the tlstmCertToTSNTable) then the
session establishment MUST fail, the
tlstmSessionInvalidClientCertificates object is incremented
and processing stops.

tp> And what if no client cert is requested? Perhaps the client
tp> should terminate the TLS session if the initial handshake does
tp> not ask for client cert; assuming it can tell. Most likely,
tp> this will be an implementation bug on the part of the server, failing
tp> to tell the TLS library that that is what it wants, but it could be
tp> malicious. And it would be useful to have a MIB object to
tp> count this type of failure (as distinct from 'I did not like the
tp> server cert').

We could create counters to identify every particular type of error that
may result from TLS, but the number of counters would be huge and be
very specific to TLS processing. The WG has specifically avoided
management of TLS specific internals and it is hoped that future TLS and
X.509 specific MIB objects may be developed in other working groups.

You're right that problems like you've listed will result in failed
connections. It is impossible for this document to enumerate all the
possible connection failure cases without duplicating most of the TLS
and 5280 documents in the process.

tp> I say 'initial' because a common pattern when client certs are
tp> required is to establish a TLS session with only a server cert
tp> and then to re-negotiate using the secure channel and this
tp> time asking for a client cert.

That's common for applications where a client certificate isn't
required, yes. For us we always require a client cert.

--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

From forum: IETF - Isms

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T16:22:18Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mahdavi, Jamshid wrote:
...
> I might be putting some words into Joe's mouth here, but it sounded
> like you would be ok with adopting the general problem of middlebox
> discovery as a WG item, but not necessarily starting from the solution
> that we have proposed. I think that if we actually need to go back to
> starting at square one we could do that, although you'll understand why
> we'd prefer not to.

I want to start with understanding the problem and why it has to be
solved with TCP options in devices that aren't supposed to be modifying
a TCP header (as opposed to IP options in those packets).

If this were to move forward, we'd need to understand how many current
Internet standards are updated by allowing intermediate devices to
modify TCP headers.

I don't see a huge problem if these issues are addressed using the
current solution, e.g., moving forward as suggested by Wes. However, if
these cannot be sufficiently addressed, I hope we can accept a solution
that is compatible with the architecture (whether modified or completely
different - I'm not suggesting I know which is the case, though) - not
just the one that happens to be deployed.

A key question is whether this qualifies as a minor modification of TCP,
or whether this ought to be in the TSVWG. IMO, adding an option is
minor, but changing the standards to allow middleboxes to modify options
is major.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxYroACgkQE5f5cImnZrsrbQCgghukQhjWuxbhIAOYaMldsLN4
A1kAoIknMDXflTxPUx2Vyeua4xsoOk0C
=TPlf
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

From forum: IETF - tcpm

RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3

2009-12-22T15:49:56Z

Rahul,

> > the Route Reflector advertizes the first C-multicast (S/*,G) Join
> route and any
> > subsequent C-multicast (S/*,G) Join route if it is better than
> previously
> > selected,
>
> No. As specified in section 11.4 the Route Reflector advertises an
> aggregated C-multicast route.
>
> > with the corresponding to the new best route ORIGINATOR_ID.

You conveniently omitted this statement..

> The entire text in section 11.4 describes how a Route Reflector
> aggregates C-multicast routes.

Well, this doesn't answer my question.

> At least two vendors with an inter-operable implementation have had no
> trouble interpreting section 11.4. So despite your mis-interpretations
> the spec is serving its purpose.

I never said that section 11.4 (as it is written) produces non-interoperable implementations.

> And finally, I am done repeating myself.

Same for me.

Maria

> > > -----Original Message-----
> > > From: l3vpn-bounces@... [mailto:l3vpn-bounces@...] On
> Behalf
> > > Of Rahul Aggarwal
> > > Sent: Monday, December 21, 2009 2:21 PM
> > > To: Robert Raszuk
> > > Cc: Thomas Morin; L3VPN
> > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A
> > > /sectionA.1.1.3
> > >
> > >
> > > Robert,
> > >
> > > On Mon, 21 Dec 2009, Robert Raszuk wrote:
> > >
> > > > Rahul,
> > > >
> > > > >> Regarding the routing *churn*, section 11.4 says further down
> > > that:
> > > > >>
> > > > >> â€To further reduce the routing churn due to C-multicast
> routes
> > > changes
> > > > >> a Route Reflector that re-advertises a C-multicast route
> SHOULD
> > > set
> > > > >> the Next Hop field of the MP_REACH_NLRI attribute of the
> route
> > > to an
> > > > >> IP address of the Route Reflector."
> > > > >>
> > > > >> Which, in fact, doesnâ€™t reduce routing churn.
> > > > >>
> > > > >
> > > > > Incorrect. The text you quoted *does* reduce routing churn due
> to
> > > > > C-multicast route changes. This is because it ensures that a
> Route
> > > > > Reflector advertises a C-multicast route, for a given (C-S/*,
> C-G)
> > > only
> > > > > when it receives the first route for the (C-S/*. C-G) from a
> > > client. It
> > > > > also ensures that a Route Reflector doesn't withdraw a C-
> multicast
> > > route
> > > > > for a given (C-S/*, C-G) as long as it has at least one route
> from
> > > a
> > > > > client for the (C-S/*, C-G).
> > > >
> > > > Incorrect.
> > > >
> > > > As Maria have said correctly *the* quoted text does not reduce
> > > routing
> > > > churn.
> > > >
> > > > The procedure you are spelling out are not reflected in the above
> > > > paragraph. At least not in version 8 of the
> > > > draft-ietf-l3vpn-2547bis-mcast-bgp.
> > > >
> > >
> > > That is an incorrect interpretation of the text in section 11.4.
> The
> > > procedure I spelled out follows from the text in section 11.4.
> > >
> > >
> > > rahul
> >
> >

From forum: IETF - L3vpn

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T15:48:53Z

WARNING: contains banned part

I'd just like to echo some of Andrew's points. We have a group of authors with a history of working with the IETF directly or with IETF standards extensively, and when we came together to start working on this we came to it with the mindset of wanting to do the right thing.

I think we have heard some very supportive statements from some people on the list. In my interpretation, we have heard a couple of key things:

- There is a need for an in-band discovery mechanism. Several people have said this, and we also know from practical experience that there is such a need in our products and in the products of other people working in this space.

- We don't want people camping out on unallocated option numbers for this.

We have also heard a couple of key objections:

- The use of this option will consume too much space in the TCP header. With regards to this point, my observation would be that options are, by definition, "optional". Especially in the case of middleboxes, it is up to those devices to decide what would be the best set of options to choose for their particular application. In our experience, space has not been a problem, and if it becomes one we would have to make such trade-offs.

- I believe there may be some question as to whether vendors would adopt this if a standard were created. We can only speak for ourselves of course, but we would certainly intend to adopt it. Speaking in general terms, customers like it when vendors follow standards, so I can't see why other vendors would not also follow suit if a standard is provided.

- Finally, I think there was also some question early on about the actual usefulness of the mechanism we've proposed. If we take this on as a WG item this is something we'd be happy to get back to discussing.

I might be putting some words into Joe's mouth here, but it sounded like you would be ok with adopting the general problem of middlebox discovery as a WG item, but not necessarily starting from the solution that we have proposed. I think that if we actually need to go back to starting at square one we could do that, although you'll understand why we'd prefer not to.

It sounds like in either event we should probably plan for some type of in-person discussions at the next IETF. The March IETF will be pretty convenient for us and I think we could commit to some of us being present to take the next steps.

--J

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

winmail.dat (5K) Download Attachment

From forum: IETF - tcpm

AUTO: Tom Beglin/Tucson/IBM is out of the office. (returning 01/04/2010)

2009-12-22T15:14:43Z

I am out of the office until 01/04/2010.

Note: This is an automated response to your message "nfsv4 Digest, Vol 68, Issue 21" sent on 12/22/09 13:00:12.

This is the only notification you will receive while this person is away.
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4

From forum: IETF - nfsv4

Re: Gen-ART review of draft-ietf-tls-renegotiation-01

2009-12-22T15:07:20Z

Thanks!

Now I just need to figure out how to get xml2rfc to spit out the URL.

-Ekr

On Tue, Dec 22, 2009 at 2:24 PM, Steve Dispensa
<dispensa@...> wrote:

> This will be a stable link:
>
> http://www.phonefactor.com/Renegotiating_TLS.pdf
>
> -Steve
>
> On Dec 21, 2009, at 6:37 PM, "Eric Rescorla" <ekr@...> wrote:
>
>> Steve,
>>
>> can you send me a link to a permanent home?
>>
>> -Ekr
>>
>>
>> On Mon, Dec 21, 2009 at 9:36 AM, Vijay K. Gurbani
>> <vkg@...> wrote:
>>>
>>> Steve Dispensa wrote:
>>>>
>>>> I tried to send this the other day bit it doesn't look like it went
>>>> through. I was just going to say that PhoneFactor would be glad to
>>>> provide a
>>>> permanent home for the document.
>>>
>>> Steve: I did see that email. That sounds good.
>>>
>>> Thanks,
>>>
>>> - vijay
>>> --
>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>>> Web: http://ect.bell-labs.com/who/vkg/
>>>
>

_______________________________________________
Gen-art mailing list
Gen-art@...
https://www.ietf.org/mailman/listinfo/gen-art

From forum: IETF - Gen-art

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T14:41:58Z

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> That said, whether it will actually help to fix the present situation
> seems uncertain.

There is a very good chance that Blue Coat will in fact use the new
option kind if it is allocated. As our software in the field is updated,
use of the experimental kind for this no-longer-experimental purpose
will go down. Our competitors use techniques that are similar enough to
ours to use this option as well.

Andrew

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

From forum: IETF - tcpm

Last Call: draft-ietf-6man-iana-routing-header (IANA Allocation Guidelines for the IPv6 Routing Header) to Proposed Standard

2009-12-22T14:35:34Z

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:

- 'IANA Allocation Guidelines for the IPv6 Routing Header '
<draft-ietf-6man-iana-routing-header-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@... mailing lists by 2010-01-12. Exceptionally,
comments may be sent to iesg@... instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6man-iana-routing-header-00.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19120&rfc_flag=0

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

From forum: IETF - IETF-Announce

Last Call: draft-ietf-6man-iana-routing-header (IANA Allocation Guidelines for the IPv6 Routing Header) to Proposed Standard

2009-12-22T14:35:29Z

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:

- 'IANA Allocation Guidelines for the IPv6 Routing Header '
<draft-ietf-6man-iana-routing-header-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@... mailing lists by 2010-01-12. Exceptionally,
comments may be sent to iesg@... instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6man-iana-routing-header-00.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19120&rfc_flag=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@...
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

From forum: IETF - ipv6

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

2009-12-22T14:34:08Z

At 11:05 22-12-2009, Joe Abley wrote:
>Why?

Some future IAB would have a list of names and the appropriate reference.

>The purposes of the document under review is described fairly
>succinctly in section 1:
>
> 1. to create a new IANA registry called "ARPA Reserved Names" (see
> Section 4);
>
> 2. to define the special considerations of a single name SINK.ARPA,
> a name which is defined never to exist (see Section 2);
>
> 3. to allow the procedures by which the ARPA zone is maintained, as
> documented in [RFC3172], to be modified for names present in the
> ARPA Reserved Names registry according to the special
> characteristics of those names (see Section 5).
>
>Which of those three purposes are you suggesting the AS112 project
>could help with?

None of the above. I said "The operational utility could be
addressed by a project similar to AS112" [1].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg59778.html

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

From forum: IETF - IETF

Gen-ART review of draft-ietf-sipping-config-framework-16

2009-12-22T14:30:08Z

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sipping-config-framework-16
Reviewer: Pete McCann
Review Date: 2009-12-22
IETF LC End Date: 2009-12-24
IESG Telechat date: unknown

Summary: One big issue to discuss

Major issues:

I don't understand why the local network needs to be involved
in SIP provisioning. The end-to-end principle should dictate
that SIP is an application that runs transparently over intervening
networks.

From Section 3.2:
In such cases, local
network providers may wish to provide local network information such
as bandwidth constraints to the devices.
Why should the bandwidth constraints applicable to SIP be any different
from the bandwidth constraints applied to any other application?

I suggest dropping the local-network profile type.

Minor issues:

Figure 5 is confusing: it shows user A obtaining service before
user A's profile is downloaded. Similar for user B. Shouldn't
the profile be downloaded to the kiosk before service is provided?

Section 5.2.1:
Additionally, the device MUST authenticate the PDS
to ensure that it is obtaining sensitive profile data from a valid
PDS, except in the bootstrapping scenario.
Why not in the bootstrapping scenario? That seems to be the most
critical
operation.

Nits/editorial comments:

Section 5.1.4.2:
it MUST be
use
SHOULD BE:
it MUST use

Section 9:
The framework specified in this documents
SHOULD BE:
The framework specified in this document

Section 9.1:
in the absence TLS
SHOULD BE:
in the absence of TLS

_______________________________________________
Gen-art mailing list
Gen-art@...
https://www.ietf.org/mailman/listinfo/gen-art

From forum: IETF - Gen-art

Re: Gen-ART review of draft-ietf-tls-renegotiation-01

2009-12-22T14:24:49Z

This will be a stable link:

http://www.phonefactor.com/Renegotiating_TLS.pdf

-Steve

On Dec 21, 2009, at 6:37 PM, "Eric Rescorla" <ekr@...> wrote:

> Steve,
>
> can you send me a link to a permanent home?
>
> -Ekr
>
>
> On Mon, Dec 21, 2009 at 9:36 AM, Vijay K. Gurbani
> <vkg@...> wrote:
>> Steve Dispensa wrote:
>>>
>>> I tried to send this the other day bit it doesn't look like it went
>>> through. I was just going to say that PhoneFactor would be glad to
>>> provide a
>>> permanent home for the document.
>>
>> Steve: I did see that email. That sounds good.
>>
>> Thanks,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>> Web: http://ect.bell-labs.com/who/vkg/
>>

_______________________________________________
Gen-art mailing list
Gen-art@...
https://www.ietf.org/mailman/listinfo/gen-art

From forum: IETF - Gen-art

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T14:16:58Z

Speaking for myself, I think this is probably the right thing to do,
and would support the work in TCPM if adopted.

That said, whether it will actually help to fix the present situation
seems uncertain. However, what does it cost us if we spec this out
as Experimental and it ends up not getting used? Some years down the
line, it can be classed as Historic and the option number can be
reaped. I don't see a problem with that.

The concern expressed about options space is interesting to me, having
grappled with that problem myself in the past. For the purposes of
this option, which is being used by middleboxes rather than end-hosts,
it seems to me like as long as it fails safe and disables either this
portion of the discovery process or the optimization it permits, when
there's not enough space, then it seems acceptable to me. It's not
ideal, but seems to be a step better than allowing chaos to reign, as
Andrew tells us it is, and I think that's fitting with the spirit of
the draft.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: Andrew Knutsen [mailto:andrew.knutsen@...]
>Sent: Tuesday, December 22, 2009 5:02 PM
>To: Joe Touch
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; rick jones;
>tcpm@...
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>
> Well, I think our positions are clear, and I doubt they're going to
>change. Its up to the rest of the group, as far as I'm concerned. I've
>invested a lot of time trying to do the right thing here, but at some
>point one just has to rely on the wisdom of the collective.
>
>Andrew
>
>Joe Touch wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Andrew Knutsen wrote:
>
>
> Joe Touch wrote:
>
>
> FWIW, what I was saying was closer to:
>
> Vendors are violating the existing specs. It is
>not clear
> why we should expect them to follow new specs.
>
>
>
> Which spec is being violated, other than the implicit
>directive to
> not do anything thats already in a spec?
>
>
>
> The use of TCP option numbers other than experimental.
> RFC4727 defines those numbers.
>
>
>
> There are allowances in the spec for experimental
>options. The claim is
> that these are not the option numbers being used.
>
>
>
> In fact, one vendor (us ;-), is using the experimental
>kind.
> Unfortunately, that kind is not intended for deployment.
>
>
>
> Right - that's why this is the correct next step. I'm not
>disagreeing
> with that part.
>
>
>
> WAN Optimization is not an experiment. I'll say it
>again. WAN
> Optimization is not an experiment. Its a billion dollar
>industry.
>
>
>
> Please see the Tao of the IETF. Experimental also means there are
> unanswered questions to a protocol that has not yet been approved
>for
> standards track, so yes, this is an experiment.
>
>
>
> The TCP roadmap describes the use of existing options.
>It's not clear
> that there is space for the option this proposal
>describes. I've raised
> that on this list before.
>
>
> This option is already in wide use, with very few (if
>any) space
> problems. I'll say it again. This option is already in
>wide use, with
> very few (if any) space problems.
>
>
>
> You can say it a third time - it won't make it any more relevant.
> Simultaneous open is never seen on some nodes, but that doesn't
>mean
> it's any less relevant in the standard, or that we should remove
>those
> protocol states.
>
> What we see in the wild *today* is only a subset of what we design
>a
> protocol for.
>
>
>
> FWIW, I wasn't saying we should never change TCP, or
>that this change
> would never happen. I am saying that we don't seem to
>have a viable
> change that is consistent with the whole of how TCP is
>used in the
> Internet. That doesn't mean it doesn't already work in
>specific places.
>
>
> I'll say it again. This is in fact how TCP is used in
>the Internet.
>
>
>
> See above.
>
>
>
> I was implying that taking this on as a WG *document*
>was premature. We
> can certainly take it on as an issue and see whether
>we have consensus
> on how to proceed, but I didn't see that yet.
>
>
> At some point I'm going to get tired of repeating myself.
>At that
> point, if this proposal dies, we may try for "Informational"
>status.
> However, that may not be sufficient to compel our
>organization to change
> over to the new kind, much less providing motivation for
>other
> organizations to do the same.
>
>
>
> Informational is not an end-run around a WG, either. If the WG
>thinks
> that this option is a bad idea (e.g., not compatible with other
>uses of
> the option space, etc.), then it may not be documented as a spec -
>it
> could as easily be documented in a future "TCP implementation
>issues" RFC.
>
> Just plopping something out there is not justification for the
>IETF to
> standardize it.
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
> iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
> =Ogon
> -----END PGP SIGNATURE-----
>
>

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

From forum: IETF - tcpm

MARTINI Virtual Interim Meeting

2009-12-22T14:15:03Z

What: MARTINI Virtual Interim Meeting

January 7, 2010 from 11 AM - 1 PM Pacific Time

Topics:

- Discussions of currently deployed mechanisms for multiple AOR
registration, and their pros and cons

- Drafts describing solutions that (hopefully) improve upon existing
deployed mechanisms

Logistics: we'll request WebEx, so please watch the MARTINI mailing list
at
http://www.ietf.org/mail-archive/web/martini/current/maillist.html for
logistic details
_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

I-D ACTION:draft-ietf-proto-wgdocument-states-00.txt

2009-12-22T14:15:01Z

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title : Definition of Working Group Document States
Author(s) : E. Juskevicius
Filename : draft-ietf-proto-wgdocument-states-00.txt
Pages : 8
Date : 2009-12-21

This document contains definitions for all of the different states
that documents (viz. Internet-Drafts) may experience with an IETF
working group. The first state occurs when an I-D is submitted for
consideration as a working group item, and the last state is either
when the I-D is sent to the IESG for publication, or declared as
"dead". The intended purpose of this Internet-Draft is to serve as
a basis for defining requirements to update the I-D tracker tool, to
permit WG Chairs and other persons to view the progression of all
documents through working groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgdocument-states-00.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-proto-wgdocument-states-00.txt (73 bytes) Download Attachment

From forum: IETF - I-D-Announce

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T14:02:15Z

Well, I think our positions are clear, and I doubt they're going to change. Its up to the rest of the group, as far as I'm concerned. I've invested a lot of time trying to do the right thing here, but at some point one just has to rely on the wisdom of the collective.

Andrew

Joe Touch wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andrew Knutsen wrote:

Joe Touch wrote:

FWIW, what I was saying was closer to:

    Vendors are violating the existing specs. It is not clear
    why we should expect them to follow new specs.

   Which spec is being violated, other than the implicit directive to
not do anything thats already in a spec?


The use of TCP option numbers other than experimental.
RFC4727 defines those numbers.

There are allowances in the spec for experimental options. The claim is
that these are not the option numbers being used.

   In fact, one vendor (us ;-), is using the experimental kind. 
Unfortunately, that kind is not intended for deployment.


Right - that's why this is the correct next step. I'm not disagreeing
with that part.

   WAN Optimization is not an experiment.  I'll say it again.  WAN
Optimization is not an experiment.  Its a billion dollar industry.


Please see the Tao of the IETF. Experimental also means there are
unanswered questions to a protocol that has not yet been approved for
standards track, so yes, this is an experiment.

The TCP roadmap describes the use of existing options. It's not clear
that there is space for the option this proposal describes. I've raised
that on this list before.

   This option is already in wide use, with very few (if any) space
problems.  I'll say it again.  This option is already in wide use, with
very few (if any) space problems.


You can say it a third time - it won't make it any more relevant.
Simultaneous open is never seen on some nodes, but that doesn't mean
it's any less relevant in the standard, or that we should remove those
protocol states.

What we see in the wild *today* is only a subset of what we design a
protocol for.

FWIW, I wasn't saying we should never change TCP, or that this change
would never happen. I am saying that we don't seem to have a viable
change that is consistent with the whole of how TCP is used in the
Internet. That doesn't mean it doesn't already work in specific places.

   I'll say it again.  This is in fact how TCP is used in the Internet.


See above.

I was implying that taking this on as a WG *document* was premature. We
can certainly take it on as an issue and see whether we have consensus
on how to proceed, but I didn't see that yet.

   At some point I'm going to get tired of repeating myself.  At that
point, if this proposal dies, we may try for "Informational" status.  
However, that may not be sufficient to compel our organization to change
over to the new kind, much less providing motivation for other
organizations to do the same.


Informational is not an end-run around a WG, either. If the WG thinks
that this option is a bad idea (e.g., not compatible with other uses of
the option space, etc.), then it may not be documented as a spec - it
could as easily be documented in a future "TCP implementation issues" RFC.

Just plopping something out there is not justification for the IETF to
standardize it.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
=Ogon
-----END PGP SIGNATURE-----

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

From forum: IETF - tcpm

WG Action: Multiple AoR reachabiliTy InformatioN Indication (martini)

2009-12-22T14:00:01Z

A new IETF working group has been formed in the Real-time Applications and
Infrastructure Area. For additional information, please contact the Area
Directors or the WG Chairs.

Multiple AoR reachabiliTy InformatioN Indication (MARTINI)
---------------------------------------------------------
Last Modified: 2009-12-08

Proposed Chair(s):
Spencer Dawkins <spencer@...>
Bernard Aboba <bernard_aboba@...>

Real-time Applications and Infrastructure Area Director(s):
Robert Sparks <rjsparks@...>
Cullen Jennings <fluffy@...>

Real-time Applications and Infrastructure Area Advisor:
Cullen Jennings <fluffy@...>

Technical Advisor(s):

Mailing Lists:
General Discussion: martini@...
To Subscribe: martini-request@...
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/martini/index.html

Description of Working Group

The MARTINI working group is chartered to specify a means by which an
entity that is authoritative for SIP URIs can dynamically register
reachability information for multiple Addresses of Record ("AORs") with a
service provider.

The SIP protocol [RFC 3261 and its extensions] supports multiple means of
obtaining the connection information necessary to deliver out-of-dialog
SIP requests to their intended targets. When a SIP Proxy needs to send a
request to a target AOR within its domain, it can use a location
service to obtain the registered contact URI, together with any associated
path information [RFC 3327], and build a route set to reach the target
UA(s). The SIP REGISTER method can be used to register contact URIs and
path information. SIP-outbound [RFC 5626] enhances this mechanism to cater
for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a
request to a target for which it is not authoritative, the UA/Proxy can
use RFC3263 procedures for using DNS to resolve the next-hop connection
information.

In practice, many small and medium-sized businesses use a SIP-PBX that is
authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a
registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs
register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service
Provider (SSP) provides SIP peering/trunking capability to the SIP PBX.
The SIP-PBX must be reachable from the SSP so that the SSP can route
inbound SIP requests for the AoRs addressed to the SIP PBX, routing these
requests to the SIP-PBX itself for onward delivery to registered UAs.

Experience has shown that existing mechanisms are not always sufficient
to
support SIP-PBXs for small/medium businesses. Since a single SSP may
support multiple thousands of such SMB SIP-PBX's, it is impractical and
cost-prohibitive to manually provision their IP addresses in every SIP
node along paths to those SIP-PBXs. Furthermore, IP addresses can be
dynamically assigned and therefore can potentially change relatively
frequently.

In current deployments, dynamic reachability mechanisms based on the SIP
REGISTER method are commonly used. Effectively, a single REGISTER request
registers the AoR of the SIP-PBX, so that any out-of-dialog request
targeted at a SIP URI for which the SIP-PBX is authoritative can be
delivered from the SSP to the SIP-PBX. However, implementations of this
mechanism vary in details, leading to interoperability issues between
SIP-PBXs and SSPs, and the need for equipment to support different
variants.

The task of this working group is to to standardize a multiple-AoR
registration mechanism for SIP that can be widely deployed by service
providers at large scale. The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may be
included.

The solution will utilize existing SIP mechanisms to the extent possible,
although it is anticipated that small protocol extensions are likely to be
required, and hence a standards track (rather than BCP) deliverable is
expected. The solution will accommodate existing SIP extensions relating
to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by
ensuring that they are not precluded from use in the context of multiple
AoR registrations. The solution will incorporate a compatibility mechanism
to ensure a deterministic outcome when interworking with entities that do
not support multiple AoR registration.

The working group will coordinate with SIP Forum and other industry
groups
on requirements and will coordinate its work with other IETF working
groups including DRINKS and SIPCORE.

Goals and Milestones
Dec 2009 Solicit solution-space drafts
Jan 2010 Interim meeting
Jan 2010 Adopt Working Group draft
Feb 2010 First Working Group Last Call
Mar 2010 Second Working Group Last Call
Apr 2010 Multiple AoR Registration specification to IESG (PS)
Jul 2010 Close or recharter working group
_______________________________________________
IETF-Announce mailing list
IETF-Announce@...
https://www.ietf.org/mailman/listinfo/ietf-announce

From forum: IETF - IETF-Announce

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T13:46:37Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Knutsen wrote:
> Joe Touch wrote:
>> FWIW, what I was saying was closer to:
>>
>> Vendors are violating the existing specs. It is not clear
>> why we should expect them to follow new specs.
>>
>
> Which spec is being violated, other than the implicit directive to
> not do anything thats already in a spec?

The use of TCP option numbers other than experimental.
RFC4727 defines those numbers.

>> There are allowances in the spec for experimental options. The claim is
>> that these are not the option numbers being used.
>>
>
> In fact, one vendor (us ;-), is using the experimental kind.
> Unfortunately, that kind is not intended for deployment.

Right - that's why this is the correct next step. I'm not disagreeing
with that part.

> WAN Optimization is not an experiment. I'll say it again. WAN
> Optimization is not an experiment. Its a billion dollar industry.

Please see the Tao of the IETF. Experimental also means there are
unanswered questions to a protocol that has not yet been approved for
standards track, so yes, this is an experiment.

>> The TCP roadmap describes the use of existing options. It's not clear
>> that there is space for the option this proposal describes. I've raised
>> that on this list before.
>
> This option is already in wide use, with very few (if any) space
> problems. I'll say it again. This option is already in wide use, with
> very few (if any) space problems.

You can say it a third time - it won't make it any more relevant.
Simultaneous open is never seen on some nodes, but that doesn't mean
it's any less relevant in the standard, or that we should remove those
protocol states.

What we see in the wild *today* is only a subset of what we design a
protocol for.

>> FWIW, I wasn't saying we should never change TCP, or that this change
>> would never happen. I am saying that we don't seem to have a viable
>> change that is consistent with the whole of how TCP is used in the
>> Internet. That doesn't mean it doesn't already work in specific places.
>
> I'll say it again. This is in fact how TCP is used in the Internet.

See above.

>> I was implying that taking this on as a WG *document* was premature. We
>> can certainly take it on as an issue and see whether we have consensus
>> on how to proceed, but I didn't see that yet.
>
> At some point I'm going to get tired of repeating myself. At that
> point, if this proposal dies, we may try for "Informational" status.
> However, that may not be sufficient to compel our organization to change
> over to the new kind, much less providing motivation for other
> organizations to do the same.

Informational is not an end-run around a WG, either. If the WG thinks
that this option is a bad idea (e.g., not compatible with other uses of
the option space, etc.), then it may not be documented as a spec - it
could as easily be documented in a future "TCP implementation issues" RFC.

Just plopping something out there is not justification for the IETF to
standardize it.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
=Ogon
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

From forum: IETF - tcpm

Re: Editorial comments on draft-ietf-6man-subnet-model-06

2009-12-22T13:42:14Z

Hi Hemant.

It seems we have agreement on all but one point. Great!

See below.

> >I'm also confused by the use of Neighbor Cache in section 2. AFAIK it
> is
> >the prefix list plus the *destination cache* (plus default router list)
> >which corresponds to the forwarding table in a host. The neighbor cache
> >is merely a generalization of the ARP cache in IPv4. The text uses
> >"neighbor cache" in two places where I'd expect to see "destination
> cache".
> >Thus I think we need to change FROM
> > The conceptual sending algorithm of [RFC4861] defines a Prefix
> > List and Neighbor Cache. The combination of Prefix List and
> > Neighbor Cache form what many implementations consider to be
> the
> > IP data forwarding table for a host.
> >TO
> > The conceptual sending algorithm of [RFC4861] defines a Prefix
> > List and Destination Cache. The combination of Prefix List and
> > Destination Cache form what many implementations consider to be
> the
> > IP data forwarding table for a host.

> >---

> <hs> The reason we worded the text this way was to point out incorrect
> implementations like BSD that had combined the ND-cache with the
> Destination Cache and suffered from problems in on-link determination as
> a result. We could change the text to include the Prefix List, the
> Destination Cache, the Default Router List, and Neighbor Cache. You
> see, once the next-hop determination is made, to forward a packet out,
> the node has to look up the entry in the Neighbor Cache for the
> link-layer address. However, if we wanted to talk just about Layer 3
> information, we could include just the Prefix List, the Destination
> Cache, and the Default Router List.=20
> </hs>

I prefer the latter option, i.e., just adding "default router list" to
the first sentence.

The reason is that (going back to Section 5.2 of RFC 4861), for the
purposes of on-link determination, one doesn't use the Neighbor
Cache. One need only perform next-hop determination (which leads to a
Destination Cache Entry). At that point, if the next hop address in
the selected entry matches the address in the packet, you know its
on-link.

> >This should be "Destination Cache" instead of "Neighbor Cache":
> > determination can affect the state of ND: through updating the
> > Prefix List or the Neighbor Cache. Through deprecating the
> last

> >---

> <hs> Good catch, this should read "Destination Cache", not "Neighbor
> Cache". However, please note that the last sentence of this paragraph
> should remain as "Neighbor Cache".

Yes, I agree.

> > The on-link definition in the Terminology section of [RFC4861], as
> > modified by this document, defines the complete list of cases where
> > an address is considered on-link. Individual address entries can
> be

> >Change sentence to:

> > The on-link definition in the Terminology section of [RFC4861], as
> > modified by this document, defines the complete list of cases
> > where a node considers an address to be on-link.

> <hs> Agree with new text provided "node" in new text is changed to
> "host".
> </hs>

OK.

> >---

> > 2. In the absence of other sources of on-link information,
> including
> > Redirects, if the RA advertises a prefix with the on-link(L)
> bit
> > set and later the Valid Lifetime expires, the host MUST then
> > consider addresses of the prefix to be off-link, as specified
> by
> > the PIO paragraph of section 6.3.4 of [RFC4861].

> >Better (above is not quite right):

> > 2. In the absence of other sources of on-link information,
> > including Redirects, if the RA advertises a prefix with the
> > on-link(L) bit set and later the Valid Lifetime expires, the
> > host MUST then update its Prefix List w.r.t. to the entry. In
> > most cases, this will result in the addresses covered by the
> > prefix defaulting back to being considered off-link, as
> > specified by the PIO paragraph of section 6.3.4 of
> > [RFC4861]. However, there are cases where an address could be
> > covered by multiple entries in the Prefix List, where
> > expiration of one prefix would result in destinations then
> > being covered by a different entry.

> <hs> Agree with new text subject to changing "w.r.t. to" to "with
> respect to". Prefix list entries can overlap as you pointed out.
> </hs>

Agreed.

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@...
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

From forum: IETF - ipv6

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T13:33:11Z

Joe Touch wrote:
> FWIW, what I was saying was closer to:
>
> Vendors are violating the existing specs. It is not clear
> why we should expect them to follow new specs.
>

Which spec is being violated, other than the implicit directive to
not do anything thats already in a spec?

> There are allowances in the spec for experimental options. The claim is
> that these are not the option numbers being used.
>

In fact, one vendor (us ;-), is using the experimental kind.
Unfortunately, that kind is not intended for deployment.

WAN Optimization is not an experiment. I'll say it again. WAN
Optimization is not an experiment. Its a billion dollar industry.

> The TCP roadmap describes the use of existing options. It's not clear
> that there is space for the option this proposal describes. I've raised
> that on this list before.
>

This option is already in wide use, with very few (if any) space
problems. I'll say it again. This option is already in wide use, with
very few (if any) space problems.

> FWIW, I wasn't saying we should never change TCP, or that this change
> would never happen. I am saying that we don't seem to have a viable
> change that is consistent with the whole of how TCP is used in the
> Internet. That doesn't mean it doesn't already work in specific places.
>

I'll say it again. This is in fact how TCP is used in the Internet.

> I was implying that taking this on as a WG *document* was premature. We
> can certainly take it on as an issue and see whether we have consensus
> on how to proceed, but I didn't see that yet.
>

At some point I'm going to get tired of repeating myself. At that
point, if this proposal dies, we may try for "Informational" status.
However, that may not be sufficient to compel our organization to change
over to the new kind, much less providing motivation for other
organizations to do the same.

Andrew

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

From forum: IETF - tcpm

Protocol Action: 'IMAP4 Keyword Registry' to Proposed Standard

2009-12-22T13:24:32Z

The IESG has approved the following document:

- 'IMAP4 Keyword Registry '
<draft-melnikov-imap-keywords-10.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-keywords-10.txt

Technical Summary

Over the years, some IMAP keywords (client-defined flags) have become
de-facto standard, with some specific semantics associated with them.
In some cases, different client implementors have defined and used
keywords with different names, but the same semantics. Some server
implementors decided to map such keywords to each other automatically
in order to improve cross client interoperability. In other cases,
the same keywords have been used with different semantics, causing
interoperability problems.

This document attempts to prevent further incompatible uses of IMAP
keywords by establishing an IANA registry for IMAP keywords, and by
allocating a special prefix for standardized keywords.

Working Group Summary

Nothing to note. This is a pretty straightforward creation of an IANA
registry.

Document Quality

The registry is seeded with some keywords that are already in use in
existing implementations. Experts to be Arnt Gulbrandsen and Dave
Cridland (dave.cridland@... and arnt@...)

RFC Editor Note

Note "cross client" in section 2 (across a line break) should be
cross-client.

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

From forum: IETF - IETF-Announce

Re: DNS64 interaction with plain resolvers

2009-12-22T13:22:42Z

On 22 dec 2009, at 22:14, Joel Jaeggli wrote:

>> Yes, but I don't think any of that stuff is running IPv6. We get to leave those boxes behind and make a fresh start with IPv6, where we have the chance to get most of this right (of course in a few years we'll discover what new stuff we got wrong).

> This isn't really a safe assumption anymore... cpe (from cisco/linkys
> d-link apple etc) that I see down at the local offciemax/bestbuy has
> ipv6 ready and windows vista logos applied. This stuff has whatever
> dodgy v4 implmentation it had plus whatever it chooses to do for v6 to
> meet that vista logo compliance requirement you can bet it does 6to4,
> given time to market (the firmware on my d-link was from april) that
> ship has sailed and we'll be living with it for quite some time.

I'm pretty sure the worst IPv6 CPEs are still much better than the worst IPv4 CPEs with regard to DNS issues.
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

From forum: IETF - Behave

Protocol Action: 'Authentication and Confidentiality in PIM-SM Link-local Messages' to Proposed Standard

2009-12-22T13:22:34Z

The IESG has approved the following document:

- 'Authentication and Confidentiality in PIM-SM Link-local Messages '
<draft-ietf-pim-sm-linklocal-10.txt> as a Proposed Standard

This document is the product of the Protocol Independent Multicast Working Group.

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-linklocal-10.txt

Technical Summary

RFC 4601 mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). It specifies optional mechanisms to
provide confidentiality using the ESP. Manual keying is specified as
the mandatory and default group key management solution. To deal
with issues of scalability and security that exist with manual
keying, an optional support for automated group key management
mechanism is provided. However, the procedures for implementing
automated group key management are left to other documents. This
document updates RFC 4601.

Working Group Summary

Due to limited IPsec expertise in the PIM WG, there was limited
input from the WG on this document.

Document Quality

Two independent implementations are planned for completion in the
second half of 2009.

The document had substantial improvements from a SecDir review by
Brian Weis.

The responsible AD gave a detailed review, and the document has been
updated.

Personnel

Stig Venaas (stig@...) is the Document Shepherd.
Adrian Farrel (adrian.farrel@...) is the Responsible AD.

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

From forum: IETF - pim

Protocol Action: 'Authentication and Confidentiality in PIM-SM Link-local Messages' to Proposed Standard

2009-12-22T13:22:34Z

The IESG has approved the following document:

- 'Authentication and Confidentiality in PIM-SM Link-local Messages '
<draft-ietf-pim-sm-linklocal-10.txt> as a Proposed Standard

This document is the product of the Protocol Independent Multicast Working Group.

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-linklocal-10.txt

Technical Summary

RFC 4601 mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). It specifies optional mechanisms to
provide confidentiality using the ESP. Manual keying is specified as
the mandatory and default group key management solution. To deal
with issues of scalability and security that exist with manual
keying, an optional support for automated group key management
mechanism is provided. However, the procedures for implementing
automated group key management are left to other documents. This
document updates RFC 4601.

Working Group Summary

Due to limited IPsec expertise in the PIM WG, there was limited
input from the WG on this document.

Document Quality

Two independent implementations are planned for completion in the
second half of 2009.

The document had substantial improvements from a SecDir review by
Brian Weis.

The responsible AD gave a detailed review, and the document has been
updated.

Personnel

Stig Venaas (stig@...) is the Document Shepherd.
Adrian Farrel (adrian.farrel@...) is the Responsible AD.

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

From forum: IETF - IETF-Announce

Re: poll for consensus on Middlebox Discover draft as a TCPM WG item

2009-12-22T13:17:59Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Knutsen wrote:
>
> I'll try to be nice here, but this is getting repetitious. However
> as Dr. SNMP says, "Repetition is the key to learning... I'll say it
> again... Repetition is the key to learning".
>
> Vendors cannot follow specs that do not exist. The spec will not
> exist until we adopt it. Saying we shouldn't adopt it because it hasn't
> been adopted does not seem like a reasonable argument to me.

FWIW, what I was saying was closer to:

Vendors are violating the existing specs. It is not clear
why we should expect them to follow new specs.

There are allowances in the spec for experimental options. The claim is
that these are not the option numbers being used.

> Perhaps it seems odd, or heretical, but this option, or similar, is
> in fact "existing use of the option space". This is because the fact
> that a spec does not exist does not preclude implementation and
> widespread deployment if a need (ie market) exists.

The TCP roadmap describes the use of existing options. It's not clear
that there is space for the option this proposal describes. I've raised
that on this list before.

> The area we are dealing with here, middleboxes, is a very real part
> of the Internet which is not well dealt with using the formal model of a
> layered, end-to-end TCP protocol. Lets remember the scientific method:
> rather than keeping faith in a model which does not match experience
> (and denying the incongruities), its more effective to change the model
> to fit experience.

FWIW, I wasn't saying we should never change TCP, or that this change
would never happen. I am saying that we don't seem to have a viable
change that is consistent with the whole of how TCP is used in the
Internet. That doesn't mean it doesn't already work in specific places.

I was implying that taking this on as a WG *document* was premature. We
can certainly take it on as an issue and see whether we have consensus
on how to proceed, but I didn't see that yet.

Joe

> Joe Touch wrote:
> Hi, Wes (et al.),
>
> Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>
>>>> Speaking as an individual (not a WG co-chair), it was an eye-opener
>>>> for me to discover that there are N vendors, each of which is doing
>>>> something similar to this, and they're picking their own TCP option
>>>> numbers (not getting them properly allocated and documented).
>>>>
>>>> That's "really bad".
>>>>
>
> I agree. It's hard to understand why TCPM should take this on as a WG
> item if the assumption is that the vendors won't follow the specs.
>
> So far, what I've seen in the discussion seems to blow the size of the
> options out of the water. It doesn't appear compatible with existing use
> of the option space.
>
> Taking this on as a WG item appears to both endorse the current method
> and to assume that we can find a way to develop it as a useful standard.
> It seems like we have a ways to go before reaching that conclusion.
>
> Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxN4cACgkQE5f5cImnZrs5AQCgzcYotq18srhi2a7iC6yf46/L
4B0AnA1V6tSbTO7LNndmirzoYU8+k9c9
=sqwR
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

From forum: IETF - tcpm

I-D Action:draft-ietf-mpls-tp-framework-07.txt

2009-12-22T13:15:02Z

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

Title : A Framework for MPLS in Transport Networks
Author(s) : M. Bocci, et al.
Filename : draft-ietf-mpls-tp-framework-07.txt
Pages : 46
Date : 2009-12-22

This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit-
switched carrier networks. It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support. Some of these functions are defined
in existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 25, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-07.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.

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

draft-ietf-mpls-tp-framework-07.txt (73 bytes) Download Attachment

From forum: IETF - mpls

I-D Action:draft-ietf-mpls-tp-framework-07.txt

2009-12-22T13:15:02Z

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

Title : A Framework for MPLS in Transport Networks
Author(s) : M. Bocci, et al.
Filename : draft-ietf-mpls-tp-framework-07.txt
Pages : 46
Date : 2009-12-22

This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit-
switched carrier networks. It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support. Some of these functions are defined
in existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 25, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-07.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-mpls-tp-framework-07.txt (73 bytes) Download Attachment

From forum: IETF - I-D-Announce

Re: DNS64 interaction with plain resolvers

2009-12-22T13:14:52Z

Iljitsch van Beijnum wrote:

> On 22 dec 2009, at 18:43, Andrew Sullivan wrote:
>
>>> Don't forget that we're talking about new deployments here: we don't
>>> have a decade long history of craptastic boxes to work around. There
>>> are probably only one or two boxes out there that actually do all
>>> this over IPv6 today. So we have an opportunity to tell the home
>>> gateway etc vendors to get it right. (See also the homegate bof.)
>
>> If you have a look at the work that Ray Bellis and his colleagues did
>> about gateways, you will discover that there's a lot of home gear
>> available from stores today (well, last year, but whatever) that get
>> this all horribly wrong.
>
> Yes, but I don't think any of that stuff is running IPv6. We get to leave those boxes behind and make a fresh start with IPv6, where we have the chance to get most of this right (of course in a few years we'll discover what new stuff we got wrong).

This isn't really a safe assumption anymore... cpe (from cisco/linkys
d-link apple etc) that I see down at the local offciemax/bestbuy has
ipv6 ready and windows vista logos applied. This stuff has whatever
dodgy v4 implmentation it had plus whatever it chooses to do for v6 to
meet that vista logo compliance requirement you can bet it does 6to4,
given time to market (the firmware on my d-link was from april) that
ship has sailed and we'll be living with it for quite some time.

> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

From forum: IETF - Behave

RE: Editorial comments on draft-ietf-6man-subnet-model-06

2009-12-22T13:09:14Z

Erik and Thomas,

Thanks for the review and the text - humble apologies for the delay. I
and Wes discussed your reply. Please see in line below between <hs> and
</hs>. We will post a -07 soon taking care of these comments from you.

Hemant & Wes

-----Original Message-----
>From: Erik Nordmark [mailto:erik.nordmark@...]
>Sent: Tuesday, December 08, 2009 1:43 PM
>To: IPv6 Maintenance WG; Wes Beebee (wbeebee); Hemant Singh (shemant)
>Cc: Thomas Narten
>Subject: Editorial comments on draft-ietf-6man-subnet-model-06

>I had some editorial questions and comments on
>draft-ietf-6man-ipv6-subnet-model-06 and I asked Thomas about that
>(since he contributed some new text in this area). Based on Thomas and
I
>discussion this, here are some suggested edits.

>Throughout the document the term "on-link" is still not used precisely
>in all cases. It is important to note that "on-link" is a relative
>statement, referring to one node's perspective. Other nodes on the
>same link may not have the same understanding that a particular
>destination is "on-link".

>---

>This doesn't look quite right:
> 1. The original Neighbor Discovery (ND) specification [RFC4861]
was
> unclear in its usage of the term on-link in a few places. In
> IPv6, an address is considered to be on-link (with respect to a
> specific link), if the address has been assigned to an
interface
> attached to that link.

>I read this as if the admin on node A configures some random IPv6
>address on an interface, then magically other nodes on the link will
>consider it to be on-link. It is clear that the address *is* on-link
>once it is configured, but it can't be *considered to be* on-link by
>others unless there is some protocol to convey that.

>The text would make sense if we just dropped "considered to be" above.
>But a better rewrite would be to say:
> 1. The original Neighbor Discovery (ND) specification [RFC4861]
> was unclear in its usage of the term on-link in a few places.
> In IPv6, an address is on-link (with respect to a specific
> link), if the address has been assigned to an interface
> attached to that link. Any node attached to the link can send
> a datagram directly to an on-link address without forwarding
> the datagram through a router. However, in order for a node to
> to know that a destination is on-link, it must obtain
> configuration information to that effect. In IPv6, there are
> two main ways of maintaining information about on-link
> destinations. First, a host maintains a Prefix List that
> identifies ranges of addresses that are to be considered
> on-link. Second, Redirects can identify individual
> destinations that are on-link; such Redirects update the
> Destination Cache.

<hs> Agree with new text.
</hs>

>---

>I'm also confused by the use of Neighbor Cache in section 2. AFAIK it
is
>the prefix list plus the *destination cache* (plus default router list)
>which corresponds to the forwarding table in a host. The neighbor cache
>is merely a generalization of the ARP cache in IPv4. The text uses
>"neighbor cache" in two places where I'd expect to see "destination
cache".
>Thus I think we need to change FROM
> The conceptual sending algorithm of [RFC4861] defines a Prefix
> List and Neighbor Cache. The combination of Prefix List and
> Neighbor Cache form what many implementations consider to be
the
> IP data forwarding table for a host.
>TO
> The conceptual sending algorithm of [RFC4861] defines a Prefix
> List and Destination Cache. The combination of Prefix List and
> Destination Cache form what many implementations consider to be
the
> IP data forwarding table for a host.

>---

<hs> The reason we worded the text this way was to point out incorrect
implementations like BSD that had combined the ND-cache with the
Destination Cache and suffered from problems in on-link determination as
a result. We could change the text to include the Prefix List, the
Destination Cache, the Default Router List, and Neighbor Cache. You
see, once the next-hop determination is made, to forward a packet out,
the node has to look up the entry in the Neighbor Cache for the
link-layer address. However, if we wanted to talk just about Layer 3
information, we could include just the Prefix List, the Destination
Cache, and the Default Router List.
</hs>

>Later we have an extra '-' appear that doesn't existing in the quoted
>text in RFC 4861. The draft contains
> If the Source Address is not the unspecified address and,
on-
> link layers that have addresses, the solicitation includes a

>But the text in RFC 4861 says
> description applies. If the Source Address is not the unspecified
> address and, on link layers that have addresses, the solicitation
> includes a Source Link-Layer Address option, then the recipient

>The distinction between "on link layer" (one could also say "for link
>layers") and "on-link layers" might be important, hence I think the
>misquote should be fixed.

<hs> Good catch - will remove the extra hyphen.
</hs>

>---

>This should be "Destination Cache" instead of "Neighbor Cache":
> determination can affect the state of ND: through updating the
> Prefix List or the Neighbor Cache. Through deprecating the
last

>---

<hs> Good catch, this should read "Destination Cache", not "Neighbor
Cache". However, please note that the last sentence of this paragraph
should remain as "Neighbor Cache".
</hs>

>Old:

> IPv4 implementations typically associate a netmask with an address
> when an IPv4 address is assigned to an interface. That netmask
> together with the IPv4 address designates an on-link prefix.
> Addresses that are covered by this prefix are viewed as on-link
i.e.,
> traffic to these addresses is not sent to a router. See section
> 3.3.1 in [RFC1122]. Prior to the deployment of Classless Inter-
> Domain Routing (CIDR), an address's netmask could be derived
directly
> from the address. In the absence of specifying a specific netmask
> when assigning an address, some implementations would fall back to
> deriving the netmask from the class of the address.

>New:

> IPv4 implementations typically associate a netmask with an address
> when an IPv4 address is assigned to an interface. That netmask
> together with the IPv4 address designates an on-link prefix. Nodes
> consider addresses covered by an on-link prefix to be directly
> attached to the same link as the sending node, i.e., they send
> traffic for such addresses directly rather than to a router. See
> section 3.3.1 in [RFC1122]. Prior to the development of subnetting
> [RFC950] and Classless Inter-Domain Routing (CIDR) [RFC1519], an
> address's netmask could be derived directly from the address simply
> by determining whether it was a Class A, B or C address. Today,
> assigning an address to an interface also requires specifying a
> netmask to use. In the absence of specifying a specific netmask
> when assigning an address, some implementations would fall back to
> deriving the netmask from the class of the address.

<hs> New text is fine by us.
</hs>

>---

> The reception of a Prefix Information Option (PIO) with the L-bit
set
> [RFC4861] and a non-zero valid lifetime creates (or updates) an
entry
> in the Prefix List. All the prefixes that are on the Prefix List,
> i.e., have not yet timed out, are considered to be on-link.

>change last sentence to:

> All prefixes on a host's Prefix List, i.e., have not yet timed out,
> are considered to be on-link by that host.

<hs> New text is fine by us.
</hs>

>---

> The on-link definition in the Terminology section of [RFC4861], as
> modified by this document, defines the complete list of cases where
> an address is considered on-link. Individual address entries can
be

>Change sentence to:

> The on-link definition in the Terminology section of [RFC4861], as
> modified by this document, defines the complete list of cases
> where a node considers an address to be on-link.

<hs> Agree with new text provided "node" in new text is changed to
"host".
</hs>

>---

> IPv6 packets sent using the Conceptual Sending Algorithm as
described
> in [RFC4861] only trigger address resolution for IPv6 addresses
that
> are on-link. Packets to any other address are sent to a default

>New:
>
> IPv6 packets sent using the Conceptual Sending Algorithm as
described
> in [RFC4861] only trigger address resolution for IPv6 addresses
> that the sender considers to be on-link.

<hs> New text is fine by us.
</hs>

>---

> 2. Note that Redirect Messages do not contain sufficient
information
> to signal that an address is off-link. Rather, they indicate a
> preferred next-hop that is a more appropriate choice to use
than
> the originator of the Redirect.

>new: Add new paragraph and tweak the above for better transition.

> 2. It should be noted that ND does not have a way to indicate a
> destination is "off-link". Rather, a destination is assumed
> to be off-link, unless there is explicit information
> indicating that it is on-link. Such information may later
> expire or be changed, in which case a destination may revert
> back to being considered off-link, but that is different than
> there being an explicit mechanism for signaling that a
> destination is off-link.

> Redirect Messages do not contain sufficient information to
> signal that an address is off-link. Instead, Redirect
> Messages indicate a preferred next-hop that is a more
> appropriate choice to use than the originator of the
> Redirect. ...

<hs> New text looks great.
</hs>

>---

> 3. IPv6 also defines the term "neighbor" and "link" to refer to

>s/and "link"//

>It reads incorrectly in the current sentence. Changing it to "on-link"
>(was that the original intention?) is also not quite right since
>"on-link" is a property of an IP address and not a property of a node.

<hs> Agree - removing "and link".
</hs>

>---

> 2. In the absence of other sources of on-link information,
including
> Redirects, if the RA advertises a prefix with the on-link(L)
bit
> set and later the Valid Lifetime expires, the host MUST then
> consider addresses of the prefix to be off-link, as specified
by
> the PIO paragraph of section 6.3.4 of [RFC4861].

>Better (above is not quite right):

> 2. In the absence of other sources of on-link information,
> including Redirects, if the RA advertises a prefix with the
> on-link(L) bit set and later the Valid Lifetime expires, the
> host MUST then update its Prefix List w.r.t. to the entry. In
> most cases, this will result in the addresses covered by the
> prefix defaulting back to being considered off-link, as
> specified by the PIO paragraph of section 6.3.4 of
> [RFC4861]. However, there are cases where an address could be
> covered by multiple entries in the Prefix List, where
> expiration of one prefix would result in destinations then
> being covered by a different entry.

<hs> Agree with new text subject to changing "w.r.t. to" to "with
respect to". Prefix list entries can overlap as you pointed out.
</hs>

>---

> 3. Newer implementations, which are compliant with [RFC4861] MUST
> adhere to the following rules. Older implementations, which
are
> compliant with [RFC2461] but not [RFC4861] may remain as is.
If
> the Default Router List is empty and there is no other source
of
> on-link information about any address or prefix:

>Better:

> 3. Implementations compliant with [RFC4861] MUST adhere to the
> following rules. If the Default Router List is empty and there
> is no other source of on-link information about any address or
> prefix:

<hs> Agree to new text.
</hs>

>---

> This document addresses a security concern present in [RFC4861].
As
> a result, the last bullet of the on-link definition in [RFC4861]
has
> been retracted. US-CERT Vulnerability Note VU#472363 lists the
> implementations affected.

>s/last/last two/

<hs> Agree to change.
</hs>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@...
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

From forum: IETF - ipv6

Re: Adding a spam button to MUAs

2009-12-22T12:56:34Z

Nathaniel Borenstein wrote:

>
> On Dec 22, 2009, at 12:45 PM, Michael Thomas wrote:
>>
>> And it's not like this sort of thing is anything new anyway: lots of
>> vendors have "report as
>> spam" widgets that get bolted onto the side of your favorite MUA. A
>> little standardization
>> would be nice though as it would decouple that UI hassle from the
>> actual job of filtering.
>
> Absolutely -- the report-spam UI will almost certainly be better if
> it's integrated with the MUA and agnostic regarding the spam engine
> receiving the report. The only major open question I'm hearing is how
> much information that report should contain. Clearly it should be no
> more than the number of bits that the user himself can be relied on to
> provide, where our differing opinions might be resolved via user studies.
>
> It might also be worth considering offering 1 button to most users,
> but 2 buttons to users who understand the distinction well enough to
> change a default in their MUA in order to get 2 buttons instead of 1.
> I conjecture that the users who would take that action would have a
> much lower error rate than the average user. In that scenario, most
> users would send back a single bit "unwanted" message, but
> sophisticated users could send back two (or even more?) types of
> "unwanted" message. That might be the cleanest data we could hope to
> get. -- Nathaniel

I think the problem is that if you open it up to more than one bit, it
begs the question of what the
actual number of bits such a button is. I'd say that it's probably got a
lot of bits -- far more than is
likely that any user could be bothered with.

Want/don't want is nice in its simplicity, and I suspect it's about as
much as you can expect from users.
However, there's probably a lot of data that MUA's have at their
disposal to see how you react to mail.
Like, oh say, educing the duration that you viewed a piece of mail. Or
whether you replied or forwarded.
Or whether you have a habit of deleting particular kinds of them
en-mass, and other kinds of behaviour
based data.

I think that if we stopped with this absolutist campaign of "spam/ham"
(most of us are not on some
paladin's quest against the evils of spam, after all) and focused more
on the context sensitive job of
prioritizing mail, we'd all be a lot better off.

Mike
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

From forum: IETF - Asrg

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

2009-12-22T12:41:07Z

On Dec 22, 2009, at 12:08 PM, Russ Housley wrote:

> Dave:
>
> I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document.

+1

Bob

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

From forum: IETF - IETF