3xx for Re-Invite

[Shweta . Kavishwar]

Hi All,
I would like to know if its correct to send a 3xx response for a re-Invite.
If so, then what could be the possible scenarios ?
Also refer following link : (which says 3xx to re - INVITE is allowed. IETF
meeting 52)
http://www.softarmor.com/sipwg/meets/ietf52/slides/pres-jdrosen-sip-new-bis-ietf52.ppt


Rgds,
Shweta.
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain  privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this
message in  error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted
by this email including damage from virus."


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFCs should be distributed in XML (Was: Faux Pas -- web publication in proprietary formats at ietf.org

[Stewart Bryant]

I too use Subversion and rfcdiff and xml2rfc.  But there are people  
doing work (i.e. writing docs) in the IETF that do not work this  way.  
They may find using a version control system to be time-wise  expensive 
or prohibitive, especially compared to emailing track- change-docs back 
and forth.




I would not mind swapping from to an XML package
provided it supported change-tracking, embedded comments,
highlighting, WYSWYG display, edit time spell and edit time
grammer checking, and was a simple to install and maintain
on XP.

Is there such a package?

If not, I will stick with Word and continue to exchange
change-track text with my co-authors.

- Stewart

BTW - one carrot that would tempt me away would be if the
result allowed the normative text to incorprate proper
diagrams - like ITU and IEEE - two name but two - have
use in their specifications for the last 20 or so years.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Diagrams (Was RFCs should be distributed in XML)

[Steve Crocker]

On Nov 14, 2005, at 8:56 AM, Stewart Bryant wrote:




BTW - one carrot that would tempt me away would be if the
result allowed the normative text to incorprate proper
diagrams - like ITU and IEEE - two name but two - have
use in their specifications for the last 20 or so years.



The issue of diagrams is entangled in the long-standing discussion of  
proprietary formats.  There is a huge benefit in having a format that  
*everyone* can access without difficulty or cost.  I can't begin to  
tell you the impact I felt when I walked into a university half way  
around the world in an underdeveloped country and had a graduate  
student show me some pretty sophisticated stuff he had done based on  
RFCs he had downloaded from the net.  ASCII is an enormous advantage  
from that respect.


At the same time, we have clearly hobbled ourselves in not moving  
forward with more advanced technology.  In a way, we have made  
ourselves a parody of our own success, staying locked into 1960s  
technology while we have created the technology for the twenty-first  
century.  The ITU and IEEE have progressed to PDF and other formats,  
partly because they still view paper as the primary medium.


I don't know whether this issue was covered in the TechSpec BoF  
(http://www3.ietf.org/proceedings/05nov/agenda/techspec.txt) but it  
definitely needs attention.  Perhaps this should be a separate thread  
in the discussions about publications.


Steve




Steve Crocker
[EMAIL PROTECTED]



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

On-site "Well Known Addresses"

[David Mitton]

I would be helpful if on-site "well known" addresses & URLs were 
published somewhere accessible to those whom have forgotten, or left 
their email archive on their other computer.


Thanks,
Dave.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Monday 0800 Streaming efforts for IETF64 redux

[Doug Ewell]

Joel Jaeggli  wrote:

The detailed schedule is now available. It is still subject to change. 
Streaming Begins at 0800 PST (UTC/GMT -7) Monday November 7th.


Nit: PST is UTC+8, not UTC+7.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Vancouver schedule

[Eric Rescorla]

Aaron Falk <[EMAIL PROTECTED]> writes:

> Am I the only one dissatisfied with the meeting schedule?  I find that
> the run of meetings from 1300 to 1930 is just too long, especially the
> four hour period from 1300 - 1710.  I would strongly prefer our
> 'traditional' schedule over the current one.
>
> Even if I can't know which continent I'll be meeting in, it would be
> nice to know that the daily schedule is one I can live with.  ;)

No, you're not the only one. It's particularly problematic that
there's minimal (no?) food at the first break. That's quite a long
time to go without food.

-Ekr

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

draft-rescorla-dtls-05.txt

[Rob Dugal]

How does DTLS handle datagrams containing
application data that are lost or delivered out of order? 
The draft seems to indicate that only
handshake messages are subject to re-transmission, timeouts, and re-ordering.


---
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [EMAIL PROTECTED]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [TLS] draft-rescorla-dtls-05.txt

[Eric Rescorla]

Rob Dugal <[EMAIL PROTECTED]> writes:
> How does DTLS handle datagrams containing application data that are lost 
> or delivered out of order? 
> The draft seems to indicate that only handshake messages are subject to 
> re-transmission, timeouts, and re-ordering. 

That's correct. The philosophy here is to provide an interface that's
as much like that provided by normal datagram transport protocols as
possible. Those protocols don't take care of this stuff for application
data, so neither does DTLS.

-Ekr




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Faux Pas -- web publication in proprietary formats at ietf.org

[Doug Ewell]

shogunx  wrote:


On Sun, 6 Nov 2005, Anthony G. Atkielski wrote:


shogunx writes:


Proprietary formats have no place in the IETF.  The internet belongs
to everyone, not Microsoft.


Proprietary formats don't come exclusively from Microsoft,


No, but they come with more abundence from them.  I remember unisys
and the gif debacle, among others.


Thus proving Anthony's point.  The GIF debacle had nothing to do with 
Microsoft.


--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Vancouver schedule

[Eric Allman]

--On November 10, 2005 6:54:00 AM -0800 Pete Resnick 
<[EMAIL PROTECTED]> wrote:

I think the problem with this schedule (as against Paris) is that
lunch is at the old early time (1130-1300), but dinner is at the
new later time. I *much* prefer the Paris schedule , with lunch
later *and* dinner later, to either the current schedule or the old
one. If they had reasonable refreshments earlier in the afternoon,
I could live with this schedule.


I'll add my agreement to this.  I find that lunch is so close to 
breakfast that I'm often not particularly hungry, but either (a) end 
up starving by the afternoon break, causing me to gorge on the empty 
calories, or (b) eat lunch even though I'm not hungry and then nod 
off in the early afternoon.  Either way it's bad for digestion, 
health, and attention span.  If we moved lunch from 11:30 to 12:30 I 
would be a much happier puppy.


eric

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Monday 0800 Streaming efforts for IETF64 redux

[Doug Ewell]

I burbled:

The detailed schedule is now available. It is still subject to 
change. Streaming Begins at 0800 PST (UTC/GMT -7) Monday November 
7th.


Nit: PST is UTC+8, not UTC+7.


Of course this should have been:

Nit: PST is UTC-8, not UTC-7.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Unsure of WLAN diagnosis (Re: Please make sure that you do not run your WLAN in ad hoc mode)

[Barry Leiba]

Harald wrote:
It would be a Really Good Thing if we could have equipment available in 
Dallas to locate a few of these laptops and check out what's *actually* 
going on with them (OS, drivers, configuration)


Agreed.  It can't be that difficult to find a few and see what's really
going on, and if we don't do something official, well, there are some
people out there who were pretty peeved in Vancouver... and when we're
in *Texas*, there's no telling what they might do.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Faux Pas -- web publication in proprietary formats at ietf.org

[Doug Ewell]

Stephane Bortzmeyer  wrote:


If everyone were
Voltaire, we would not need smileys to express irony.


That is awesome.  That is going straight into my fortune-cookie file.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: 'ECC Cipher Suites for TLS' to Informational RFC

[Douglas Stebila]

I am reviewing the most recent ECC in TLS draft (draft-ietf-tls- 
ecc-12.txt) for its adoption in Mozilla's Netscape Security Services  
library, and have noted some issues that I believe should resolved  
before the draft is approved as an Informational RFC.


1. DES is listed as the encryption mechanism for one of the cipher  
suites, namely TLS_ECDH_ECDSA_WITH_DES_CBC_SHA.  No other key  
agreement / signature combinations in the draft include the DES  
cipher and I recommend that this cipher suite be eliminated.  The  
small key size of DES makes it inappropriate for use with any named  
elliptic curve in the draft.  This would probably require renumbering  
the cipher suites to maintain sequential numbering, and I recommend  
changing the number of TLS_ECDH_ECDSA_WITH_NULL_SHA to 0xC0, 0x01 and  
TLS_ECDH_ECDSA_WITH_RC4_128_SHA to 0xC0, 0x02, minimizing the total  
number of changes required.


2. It appears that there is an error in the name of one of the cipher  
suites.  All of the cipher suites using NULL for bulk encryption are  
of the form "..._WITH_NULL_SHA", but the cipher suite  
TLS_ECDH_anon_NULL_WITH_SHA is not named in a similar way.  I  
recommend changing its name to TLS_ECDH_anon_WITH_NULL_SHA.


Douglas


The IESG has received a request from the Transport Layer Security  
WG to

consider the following document:

- 'ECC Cipher Suites for TLS '
as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2005-11-22.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Michael Mealling]

IMHO, standardizing on _validated_ SVG with a library of well understood 
images that represented architectural components with attached semantics 
could be used to even start validating diagrams the same way we validate 
BNFs now. There are even UML to SVG tools for turning SVG drawings 
directly into code. And there are lots of free SVG tools




-MM

Steve Crocker wrote:

The issue of diagrams is entangled in the long-standing discussion of  
proprietary formats.  There is a huge benefit in having a format that  
*everyone* can access without difficulty or cost.  I can't begin to  
tell you the impact I felt when I walked into a university half way  
around the world in an underdeveloped country and had a graduate  
student show me some pretty sophisticated stuff he had done based on  
RFCs he had downloaded from the net.  ASCII is an enormous advantage  
from that respect.




--
Michael Mealling  Masten Space Systems, Inc.
VP Business Development   473 Sapena Ct.
Office: +1-678-581-9656Suite 23
Cell: +1-678-640-6884 Santa Clara, CA 95054
http://masten-space.com/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: 'ECC Cipher Suites for TLS' to Informational RFC

[Bodo Moeller]

On Wed, Nov 09, 2005 at 10:11:30PM -0800, Douglas Stebila wrote:

>> The IESG has received a request from the Transport Layer Security WG to
>> consider the following document:
>> 
>> - 'ECC Cipher Suites for TLS '
>> as an Informational RFC

> I am reviewing the most recent ECC in TLS draft (draft-ietf-tls- 
> ecc-12.txt) for its adoption in Mozilla's Netscape Security Services  
> library, and have noted some issues that I believe should resolved  
> before the draft is approved as an Informational RFC.


> 1. DES is listed as the encryption mechanism for one of the cipher  
> suites, namely TLS_ECDH_ECDSA_WITH_DES_CBC_SHA.  No other key  
> agreement / signature combinations in the draft include the DES  
> cipher and I recommend that this cipher suite be eliminated.

The ciphersuite list in draft-ietf-tls-ecc-12.txt combines five key
exchange mechanisms (i.e., key agreement / signature combinations)
with different symmetric cryptographic schemes.  Each group uses the
same symmetric schemes -- the only exception to the pattern is this
single extra ciphersuite using DES.

This ciphersuite is in the current draft by oversight.  It was
retained for historical reasons (compatibility with initial
implementations based on earlier drafts), but there is no reason any
longer to keep it.  Thus I intend to make the following simple change
in the next revision, draft-ietf-tls-ecc-13.txt:

>   The  
> small key size of DES makes it inappropriate for use with any named  
> elliptic curve in the draft.  This would probably require renumbering  
> the cipher suites to maintain sequential numbering, and I recommend  
> changing the number of TLS_ECDH_ECDSA_WITH_NULL_SHA to 0xC0, 0x01 and  
> TLS_ECDH_ECDSA_WITH_RC4_128_SHA to 0xC0, 0x02, minimizing the total  
> number of changes required.

I.e., the lines

 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA   = { 0xC0, 0x00 }
 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA= { 0xC0, 0x01 }
 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA= { 0xC0, 0x02 }
 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0xC0, 0x03 }
 [...]

will be changed into

 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA   = { 0xC0, 0x01 }
 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA= { 0xC0, 0x02 }
 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0xC0, 0x03 }
 [...]



> 2. It appears that there is an error in the name of one of the cipher  
> suites.  All of the cipher suites using NULL for bulk encryption are  
> of the form "..._WITH_NULL_SHA", but the cipher suite  
> TLS_ECDH_anon_NULL_WITH_SHA is not named in a similar way.  I  
> recommend changing its name to TLS_ECDH_anon_WITH_NULL_SHA.

This typo also is historical in that it exists since draft revision
-01 (there's just no excuse explaining it).  I intend to change the
line that reads

 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA= { 0xC0, 0x15 }

in draft-ietf-tls-ecc-12.txt into

 CipherSuite TLS_ECDH_anon_WITH_NULL_SHA= { 0xC0, 0x15 }

for the next revision, draft-ietf-tls-ecc-13.txt.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-hutzler-spamops-05.txt

[Dave Crocker]

Pekka,

Thanks for the quick and careful review.



   Submission Authentication:
  MSAs MUST perform authentication on the identity asserted

...


==> w/ local submission, is the IP address being local sufficient?  I don't
think the doc takes a stance on this, and this is pretty important as those


You are correct.  It does not take a stand.  That is intentional.

   1) there are many, competent techniques.

   2) this is not a document about authentication (and the topic is complex).

   3) the choices for particular environments depend on multiple factors.

So we decided to state the need and leave how to satisfy it to local operators.



   Traffic Identification -- External Posting Versus Relaying:
  For email being received from outside their local
  operational environment, email service providers MUST
  distinguish between mail that will be delivered inside that
  environment, versus mail that is to be relayed back out to
  the internet.

...

==> what does traffic identification (at MTA?) have to do with message
submission ?


Assuming I've got the nature of your question correct:

"Open Relays" perform message submission, by allowing traffic to be routed 
through them, *from* the Internet and then *to* the Internet.  However they 
are not intended to be submission agents and they have been a major problem, 
exploited by spammers.  This characterization of "traffic identification" is 
to distinguish open relaying from legitimate receipt of mail that is for 
recipients within the Common Operating Group (COG)* of the receiving MTA.


When a message comes from the Internet and is destined for the COG*  that 
the MTA is part of, then that is relaying.   When it is, instead, destined 
to go back to the public Internet, it is really a message submission 
mechanism, and this BCP specifies a requirement for accountability of the 
source, during the submission event.


It is not possible to require message authentication on mail relaying 
activities, without changing the usage fundamentals of Internet Mail.  By 
contrast, it is reasonable and appropriate to require that message 
submissions authenticate their source.


So, the nature of mail coming in from the Internet needs to be distinguished 
between these two functions.


d/

--

Dave Crocker
Brandenburg InternetWorking



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Andrew Sullivan]

On Mon, Nov 14, 2005 at 09:37:41AM -0500, Steve Crocker wrote:
> The issue of diagrams is entangled in the long-standing discussion of  
> proprietary formats.  There is a huge benefit in having a format that  
> *everyone* can access without difficulty or cost.  I can't begin to  
> tell you the impact I felt when I walked into a university half way  
> around the world in an underdeveloped country and had a graduate  
> student show me some pretty sophisticated stuff he had done based on  
> RFCs he had downloaded from the net.  ASCII is an enormous advantage  
> from that respect.

What I find strange about this, though, is the reluctance to adopt
PDF.  It's a well-known open standard.  There are plenty of free
software interpreters and writers around, and Ghostscript passed the
threshold for good output 2 or 3 versions ago.  I understand the
difficulty of machine parsing, but wouldn't an XML format with human
oriented output in PDF be nice?  (I suppose I'm asking whether
there's some historical flamewar over this that I managed never to
look at, in which case I'll just keep my mouth shut.)

Of course, even if that was solved, the features of Word that other
like are not really available in most of the XML tools, AFAIK. 

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
+1 416 646 3304 x4110


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-hutzler-spamops-05.txt

[Dave Crocker]

...for recipients within the Common Operating Group (COG)* of the
receiving MTA.



Oh yeah.  I forgot to add the footnote to explain the term:

* COG:

A Common Operating Group (COG) is a collection of Internet Mail service
components subject to unified administrative operations control. These can
be any combination of user agents, submission agents, relays and delivery 
agents. Assorted processing of mail might be done in different components 
within a COG, as convenient for that environment. (For example, DKIM message 
signing or validating, may be done in an MUA, MSA, or MTA within the COG. It 
is an important choice for admin and ops of the mechanism, but not for the 
semantics.)


Although it does not have a protocol impact, COG is probably similar to the
IP-level concept of Autonomous System, in that it defines policy boundaries. 
 I suspect it also relates to a "tussle" boundary.


I have been searching for a term that characterizes this organizing
construct, and haven't found one that people like.  Last week, it was
suggested I try an acronym, so COG is a first attempt.

Anyone would does not like it is encouraged to suggest one that other folks
will like better.

d/

--

Dave Crocker
Brandenburg InternetWorking



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Please make sure that you do not run your WLAN in ad hoc mode

[Gray, Eric]

Andy,

So, I am confused.  Are you saying we should use 802.11a because 
it works better or is somehow isolated from malicious or accidental
misuse?

--
Eric 

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
--> On Behalf Of Andrew G. Malis
--> Sent: Saturday, November 12, 2005 10:14 AM
--> To: Romascanu, Dan (Dan)
--> Cc: Avri Doria; Ole Jacobsen; ietf@ietf.org
--> Subject: RE: Please make sure that you do not run your WLAN 
--> in ad hoc mode
--> 
--> Dan,
--> 
--> You must have been on 802.11b.  802.11a was solid from 
--> Tuesday morning through to the end of the week.  I was 
--> having problems on Monday with dueling access points but 
--> that was fixed by Tuesday morning.
--> 
--> Cheers,
--> Andy
--> 
--> ---
--> 
--> At 11/12/2005 06:45 +0200, Romascanu, Dan \(Dan\) wrote:
--> 
--> >I know. I am attending both the IEEE 802 Plenary meetings 
--> and the IETF 
--> >meetings for many years. I can witness first hand that the 
--> situation is 
--> >much worse at the IETF meetings than at the IEEE ones. 
--> Practically, the 
--> >network is perfect at most IEEE meetings. True, I believe 
--> that they are 
--> >outsourcing the network deployment and  its maintenance during the 
--> >meeting.
--> >
--> >As I will be attending the IEEE 802 meeting next week (in 
--> Vancouver, 
--> >but at a different hotel) I will be able to report by the 
--> end of the 
--> >week how it was. Anyway, it hardly can be worse than at 
--> the IETF meeting.
--> >During this whole IETF week I could almost never connect 
--> during the 
--> >meetings. I had to wait for the lunch break when everybody 
--> was away, or 
--> >to go to my room (at the 7th floor in the tower) to be 
--> able to connect 
--> >to the IETF wireless network.
--> >
--> >Regards,
--> >
--> >Dan
--> 
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Jari Arkko]

Andrew Sullivan wrote:


What I find strange about this, though, is the reluctance to adopt
PDF.  It's a well-known open standard.  There are plenty of free
software interpreters and writers around, and Ghostscript passed the
threshold for good output 2 or 3 versions ago.  I understand the
difficulty of machine parsing, but wouldn't an XML format with human
oriented output in PDF be nice?  (I suppose I'm asking whether
there's some historical flamewar over this that I managed never to
look at, in which case I'll just keep my mouth shut.)
 


There is. Lets not reopen the format flame war. However,
just for the record we DO have .pdf as a format that you
can submit Internet Drafts and as something that you
also get from the RFC Editor. It is required that a text
format be also provided, which I think is natural and
useful. Some of the PDF documents that people have
used have contained illustrations such as state machines.
See for instance this RFC
  ftp://ftp.rfc-editor.org/in-notes/rfc4137.pdf
and for some tool support take a look at
  http://www.arkko.com/tools/xml2pdfrfc.html


Of course, even if that was solved, the features of Word that other
like are not really available in most of the XML tools, AFAIK. 
 


I kind of like the rfcdiff feature in text format more
than the word features.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-hutzler-spamops-05.txt

[Bill Sommerfeld]

On Mon, 2005-11-14 at 12:05, Frank Ellermann wrote:
> > Anyone would does not like it is encouraged to suggest one
> > that other folks will like better.
> 
> I like Keith's terms MON / MRN (mail originating / receiving
> networks) better, because seen as sets of systems they can be
> different.  An outsourced backup MX would be still a part of
> the "MRN" (if I got this right), but not belong to the same
> "COG".  MUAs also belong to one or more MONs / MRNs, but not
> necessarily to the same "COG" as the correponding MSA / MDA.

Yup.

The underlying anti-open-relay requirement is that the operator of any
MTA touching a message have a (possibly transitive) service-provider
relationship with either the sender or the recipient of the message.

That's fundamentally a statement about people and organizational
relationships.

- Bill



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-hutzler-spamops-05.txt

[Frank Ellermann]

Dave Crocker wrote:

> Anyone would does not like it is encouraged to suggest one
> that other folks will like better.

I like Keith's terms MON / MRN (mail originating / receiving
networks) better, because seen as sets of systems they can be
different.  An outsourced backup MX would be still a part of
the "MRN" (if I got this right), but not belong to the same
"COG".  MUAs also belong to one or more MONs / MRNs, but not
necessarily to the same "COG" as the correponding MSA / MDA.

Maybe I miss something with your new term (?)  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Andrew Sullivan]

On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote:
> There is. Lets not reopen the format flame war. However,
> just for the record we DO have .pdf as a format that you
> can submit Internet Drafts and as something that you

Ok, consider it not re-opened.  (And yes, I knew about the pdfs.  It
just struck me as odd that people were grousing about ASCII's
appearance when PDF is available.  But I'm keeping the worm-can
closed.)

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
+1 416 646 3304 x4110


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Dave Crocker]

 I understand the
difficulty of machine parsing, but wouldn't an XML format with human
oriented output in PDF be nice?  (I suppose I'm asking whether
there's some historical flamewar over this that I managed never to
look at, in which case I'll just keep my mouth shut.)


There is. Lets not reopen the format flame war. However,
just for the record we DO have .pdf as a format that you
can submit Internet Drafts and as something that you
also get from the RFC Editor. 



Folks might want to take a look at the latest xml2rfc capabilities.  See 
.  Besides making it far easier to include the 
correct boilerplate, it has the option of including pretty graphics for the 
PDF version, while using the ASCII form for the ASCII version.


This seems like a rather good transition mechanism, to see whether we really 
want/need to move away from ASCII.  (After all, the dual-stack model for 
transition is a time-honored methodology...)


d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Please make sure that you do not run your WLAN in ad hoc mode

[Joel Jaeggli]

On Mon, 14 Nov 2005, Gray, Eric wrote:


Andy,

So, I am confused.  Are you saying we should use 802.11a because
it works better or is somehow isolated from malicious or accidental
misuse?


Three things.

chipsets lack support for ibss mode in 802.11a

8 non-overlapping indoor channels in north america, makes the 802.11a 
radio noise situation more tractable. From a deployment perspective the 
map coloring problem is much easier.


All things being equal an a card has signficantly shorter range range at 
5.8ghz than a b card does at 2412ghz, and more surfaces (airwalls people 
etc) are opaque. This cuts down on the noise quite a bit.



--
Eric

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
--> On Behalf Of Andrew G. Malis
--> Sent: Saturday, November 12, 2005 10:14 AM
--> To: Romascanu, Dan (Dan)
--> Cc: Avri Doria; Ole Jacobsen; ietf@ietf.org
--> Subject: RE: Please make sure that you do not run your WLAN
--> in ad hoc mode
-->
--> Dan,
-->
--> You must have been on 802.11b.  802.11a was solid from
--> Tuesday morning through to the end of the week.  I was
--> having problems on Monday with dueling access points but
--> that was fixed by Tuesday morning.
-->
--> Cheers,
--> Andy
-->
--> ---
-->
--> At 11/12/2005 06:45 +0200, Romascanu, Dan \(Dan\) wrote:
-->
--> >I know. I am attending both the IEEE 802 Plenary meetings
--> and the IETF
--> >meetings for many years. I can witness first hand that the
--> situation is
--> >much worse at the IETF meetings than at the IEEE ones.
--> Practically, the
--> >network is perfect at most IEEE meetings. True, I believe
--> that they are
--> >outsourcing the network deployment and  its maintenance during the
--> >meeting.
--> >
--> >As I will be attending the IEEE 802 meeting next week (in
--> Vancouver,
--> >but at a different hotel) I will be able to report by the
--> end of the
--> >week how it was. Anyway, it hardly can be worse than at
--> the IETF meeting.
--> >During this whole IETF week I could almost never connect
--> during the
--> >meetings. I had to wait for the lunch break when everybody
--> was away, or
--> >to go to my room (at the 7th floor in the tower) to be
--> able to connect
--> >to the IETF wireless network.
--> >
--> >Regards,
--> >
--> >Dan
-->
-->
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

email "Common Operating Group"

[Dave Crocker]

Bill Sommerfeld wrote:


I like Keith's terms MON / MRN (mail originating / receiving
networks) better, because seen as sets of systems they can be
different.  An outsourced backup MX would be still a part of
the "MRN" (if I got this right), but not belong to the same
"COG".  MUAs also belong to one or more MONs / MRNs, but not
necessarily to the same "COG" as the correponding MSA / MDA.


Yup.



1. Having the term refer to either origination or reception means we need 
multiple terms.  I am seeking a single term.


2. Having the termr efer to either origination or reception ignores transit 
operations.  The term needs to cover those activities, too.


3.  Whether an outsourced activity falls under the administrative policies 
of the client or the operator is an interesting question, and not one with 
an obvious answer.  So the common term needs to permit either answer.


d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Please make sure that you do not run your WLAN in ad hoc mode

[Andrew G. Malis]

Joel,

Thanks - but to answer Eric directly, I was just saying that I was a 
happy camper for most of the week on 802.11a, in contrast to the 
problems some people were having on 802.11b.  I wasn't making any 
particular recommendations, but at the next IETF, if your card can 
support 802.11a, give a try and use whichever mode works best for you.


Cheers,
Andy

-

At 11/14/2005 09:29 -0800, Joel Jaeggli wrote:

On Mon, 14 Nov 2005, Gray, Eric wrote:


Andy,

So, I am confused.  Are you saying we should use 802.11a because
it works better or is somehow isolated from malicious or accidental
misuse?


Three things.

chipsets lack support for ibss mode in 802.11a

8 non-overlapping indoor channels in north america, makes the 
802.11a radio noise situation more tractable. From a deployment 
perspective the map coloring problem is much easier.


All things being equal an a card has signficantly shorter range 
range at 5.8ghz than a b card does at 2412ghz, and more surfaces 
(airwalls people etc) are opaque. This cuts down on the noise quite a bit.



--
Eric

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
--> On Behalf Of Andrew G. Malis
--> Sent: Saturday, November 12, 2005 10:14 AM
--> To: Romascanu, Dan (Dan)
--> Cc: Avri Doria; Ole Jacobsen; ietf@ietf.org
--> Subject: RE: Please make sure that you do not run your WLAN
--> in ad hoc mode
-->
--> Dan,
-->
--> You must have been on 802.11b.  802.11a was solid from
--> Tuesday morning through to the end of the week.  I was
--> having problems on Monday with dueling access points but
--> that was fixed by Tuesday morning.
-->
--> Cheers,
--> Andy
-->
--> ---
-->
--> At 11/12/2005 06:45 +0200, Romascanu, Dan \(Dan\) wrote:
-->
--> >I know. I am attending both the IEEE 802 Plenary meetings
--> and the IETF
--> >meetings for many years. I can witness first hand that the
--> situation is
--> >much worse at the IETF meetings than at the IEEE ones.
--> Practically, the
--> >network is perfect at most IEEE meetings. True, I believe
--> that they are
--> >outsourcing the network deployment and  its maintenance during the
--> >meeting.
--> >
--> >As I will be attending the IEEE 802 meeting next week (in
--> Vancouver,
--> >but at a different hotel) I will be able to report by the
--> end of the
--> >week how it was. Anyway, it hardly can be worse than at
--> the IETF meeting.
--> >During this whole IETF week I could almost never connect
--> during the
--> >meetings. I had to wait for the lunch break when everybody
--> was away, or
--> >to go to my room (at the 7th floor in the tower) to be
--> able to connect
--> >to the IETF wireless network.
--> >
--> >Regards,
--> >
--> >Dan
-->
-->
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Vancouver schedule

[Barry Leiba]

Eric Allman wrote:
If we moved lunch from 11:30 to 12:30 I would be a much 
happier puppy.


I agree, though I rather think of myself as a bear than a puppy.
I liked the Paris schedule, and lengthening the morning had another
effect: instead of one 2.5-hour slot, we had no slot longer than
2 hours.  (Actually, I would have preferred making it two 1.5-hour
slots (with a 30-minute break), rather than one 1-hour and one 2-hour
slot.)  Two and a half hours in one room, in one sitting, is really
too much.  I think the benefits dwindle, as people get restless and
often leave early... and the sessions often end early anyway, so
the extra session time is often wasted.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Diagrams (Was RFCs should be distributed in XML)

[Yaakov Stein]

 
> It just struck me as odd that people were grousing about ASCII's
appearance when PDF is available.  

People will stop complaining when the ASCII version is allowed to say
"see diagram in the PDF version".

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Please make sure that you do not run your WLAN in ad hoc mode

[Yaakov Stein]

 
> Are you saying we should use 802.11a because it 
> works better or is somehow isolated from malicious or accidental 
> misuse?

No, 802.11a is usually not as good.
That's why fewer chipsets bother supporting it, 
and thus there was less interference for those which do.

This is simply a case where in a multiple-standard environment
the less prevalent one gains an advantage.
(Another case - less common operating systems and software
are attacked by fewer viruses.)


Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Stewart Bryant]

Andrew Sullivan wrote:


On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote:


There is. Lets not reopen the format flame war. However,
just for the record we DO have .pdf as a format that you
can submit Internet Drafts and as something that you




However these are not taken as normative, so you have to
produce an ASCII equivalent, which fundamentally limits the
complexity of any normative diagram.

My view is this is a serious restriction in the power
of the "language" that we are allowed to use to describe
our protocols, but then I am a person that finds it
much easier to understand diagrams than text.

- Stewart


- Stewart


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFCs should be distributed in XML (Was: Faux Pas -- web publication in proprietary formats at ietf.org

[Bill Fenner]

On 11/14/05, Stewart Bryant <[EMAIL PROTECTED]> wrote:
> I would not mind swapping from to an XML package
> provided it supported change-tracking, embedded comments,
> highlighting, WYSWYG display, edit time spell and edit time
> grammer checking, and was a simple to install and maintain
> on XP.
>
> Is there such a package?

My xxe plugin, http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/, provides
a few of the features:
- embedded comments (with )
- WYSIKLWYG (What you see is kinda like what you get) display
- Edit time spell check

It's based on the XMLMind XML Editor, which is an excellent
cross-platform java-based XML editor, which is not open-source but has
a free "Standard Edition" and an excellent "Professional Edition".  My
plugin works fine with both, but certain features such as PDF output
are limited to the Professional Edition.

I've been pondering change tracking, in the context of copy-editing,
but I haven't come up with a complete thought yet.

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Stewart Bryant]

Yaakov Stein wrote:

 


It just struck me as odd that people were grousing about ASCII's


appearance when PDF is available.  


People will stop complaining when the ASCII version is allowed to say
"see diagram in the PDF version".




Right on the nail

- Stewart



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: email "Common Operating Group"

[Frank Ellermann]

Dave Crocker wrote:

> 1. Having the term refer to either origination or reception
> means we need multiple terms.  I am seeking a single term.

For draft-hutzler -05 ?  There you have "home network", that's
apparently the same as MON (modulo roaming MUA.r), and on the
other side you have "destination", apparently the same as MRN.

BTW, why are there non-ASCII characters in my copy ?  And why
does it say "will expire on October 6, 2006" ?  The abstract
is rather long, please check this with an id-nits tool.

IIRC one problematic term in -04 was "MDA", because it's not
defined in 2476(bis).  Is the "MDA" still undefined in -05 ?

> 2. Having the termr efer to either origination or reception
>ignores transit operations.

Redistribution / redirection are MRN + MON combined.  Where do
you need this in draft-hutzler ?  In mail-arch it's "mediator".

> The term needs to cover those activities, too.

You have anything you need for draft-hutzler, only "MDA" might
be a problem.

| Delivery Authorization:
|MDAs MUST NOT accept mail to recipients for which that MDA
|has no arrangement to perform delivery.

So far it's fine, but the real point is that the complete "MRN"
(starting with the MX) SHOULD reject any mail to recipients for
which that "MRN" has no arrangement to perform delivery or some
kind of redistribution on behalf of a known recipient.

The relevant case is MX != MDA, and to reject at the MX.  Okay,
the MUST for an MDA is also new, and probably you need this to
explain the more important SHOULD at the MX in the next draft.

You should also state that almost all mail is spam today, and
that the Return-Paths of spam are spoofed.  There are numerous
clueless postmasters out there:  This BCP is for those bying a
"barracuda" and pressing the red "start spew" button on it.

They need some fresh ammo to get their money back, after their
organization lost its mail connectivity.  You need simple terms
explaining why they will be blacklisted worldwide.

"COG" is too abstract for these postmasters, they won't get it.

Mail is spam, and spam is forged, not limited to the MAIL FROM,
but that's the important case for the "delivery authorization".

 Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Diagrams (Was RFCs should be distributed in XML)

[Gray, Eric]

Stewart,

I suspect most people prefer reading documents that contain
diagrams, but anything that limits the complexity of a diagram -
especially for documents most often read on a computer screen - is
a feature, rather than a bug.

If a diagram is included to communicate (rather than obscure) 
an idea, then readers should be able to correlate descriptive text 
to the diagram - either because the diagram is simple enough that
it is not necessary to keep referring to it, or because the entire
description can be viewed while looking at the diagram.

Sometimes language limitations are a good thing, when they
are tied to specific ways of presenting information.

--
Eric

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
--> On Behalf Of Stewart Bryant
--> Sent: Monday, November 14, 2005 2:09 PM
--> To: Andrew Sullivan
--> Cc: ietf@ietf.org
--> Subject: Re: Diagrams (Was RFCs should be distributed in XML)
--> 
--> 
--> 
--> Andrew Sullivan wrote:
--> 
--> > On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote:
--> > 
--> >>There is. Lets not reopen the format flame war. However, just for the 
--> >>record we DO have .pdf as a format that you can submit Internet Drafts

--> >>and as something that you
--> > 
--> 
--> However these are not taken as normative, so you have to 
--> produce an ASCII equivalent, which fundamentally limits the 
--> complexity of any normative diagram.
--> 
--> My view is this is a serious restriction in the power of 
--> the "language" that we are allowed to use to describe our 
--> protocols, but then I am a person that finds it much easier 
--> to understand diagrams than text.
--> 
--> - Stewart
--> 
--> 
--> - Stewart
--> 
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Jari Arkko]

Dave Crocker wrote:

Folks might want to take a look at the latest xml2rfc capabilities.  
See .  Besides making it far easier to 
include the correct boilerplate, it has the option of including pretty 
graphics for the PDF version, while using the ASCII form for the ASCII 
version.


XML2RFC has improved in this regard, e.g., it allows inclusion
of pictures for the HTML version. But I do not think even the
latest version generates .pdf nor does it appear to produce
very pretty output from xml->html->pdf. Though your favorite
XML editing tool may provide some solution for that. Nevertheless,
I've had good success in running xml->nr->pdf, but that requires
some tuning of the nroff output -- this is what the tool link that
I posted earlier does, without requiring the user to do any
extra steps or having any software beyond what regular unix
systems do by default.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Dave Crocker]

People will stop complaining when ...


Right on the nail



I suspect you underestimate our ability to keep complaining.

d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Diagrams (Was RFCs should be distributed in XML)

[Bob Braden]

  *>  
  *> > It just struck me as odd that people were grousing about ASCII's
  *> appearance when PDF is available.  
  *> 
  *> People will stop complaining when the ASCII version is allowed to say
  *> "see diagram in the PDF version".
  *> 
  *> Y(J)S
  *> 

Huh?  That has always been allowed.  What am I missing?

Bob Braden for the RFC Editor

  *> ___
  *> Ietf mailing list
  *> Ietf@ietf.org
  *> https://www1.ietf.org/mailman/listinfo/ietf
  *> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Julian Reschke]

Jari Arkko wrote:

Dave Crocker wrote:

Folks might want to take a look at the latest xml2rfc capabilities.  
See .  Besides making it far easier to 
include the correct boilerplate, it has the option of including pretty 
graphics for the PDF version, while using the ASCII form for the ASCII 
version.


XML2RFC has improved in this regard, e.g., it allows inclusion
of pictures for the HTML version. But I do not think even the
latest version generates .pdf nor does it appear to produce
very pretty output from xml->html->pdf. Though your favorite


You can get fairly good PDF using rfc2629toFo.xslt (available from 
) and Apache-Fop. See 
for instance .



...


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Stewart Bryant]

Bob Braden wrote:

  *>  
  *> > It just struck me as odd that people were grousing about ASCII's
  *> appearance when PDF is available.  
  *> 
  *> People will stop complaining when the ASCII version is allowed to say

  *> "see diagram in the PDF version".
  *> 
  *> Y(J)S
  *> 


Huh?  That has always been allowed.  What am I missing?


Please can we be quite clear on this - for the record:

I can include a normative diagram in the .pdf version of an RFC
(that is too complex to produce in ASCII art), and say in the
normative text of the ASCII version the diagram you need to
implement this protocol is in the .pdf version of this RFC?

If that is the case, I withdraw my concern and will use this
process, however I was told by a member of the IESG a
few months back that such a document would not be passed
for publication as an RFC by him.

- Stewart





Bob Braden for the RFC Editor

  *> ___
  *> Ietf mailing list
  *> Ietf@ietf.org
  *> https://www1.ietf.org/mailman/listinfo/ietf
  *> 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Bob Braden]

  *> 
  *> Bob Braden wrote:
  *> 
  *> >   *>  
  *> >   *> > It just struck me as odd that people were grousing about ASCII's
  *> >   *> appearance when PDF is available.  
  *> >   *> 
  *> >   *> People will stop complaining when the ASCII version is allowed to sa
  *> >   *> "see diagram in the PDF version".
  *> >   *> 
  *> >   *> Y(J)S
  *> >   *> 
  *> > 
  *> > Huh?  That has always been allowed.  What am I missing?
  *> 
  *> Please can we be quite clear on this - for the record:
  *> 
  *> I can include a normative diagram in the .pdf version of an RFC
  *> (that is too complex to produce in ASCII art), and say in the
  *> normative text of the ASCII version the diagram you need to
  *> implement this protocol is in the .pdf version of this RFC?

No, the .ps/.pdf is not allowed to be normative.

Bob Braden

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: email "Common Operating Group"

[Keith Moore]

> 
> 
> Bill Sommerfeld wrote:
> 
> >> I like Keith's terms MON / MRN (mail originating / receiving
> >> networks) better, because seen as sets of systems they can be
> >> different.  An outsourced backup MX would be still a part of
> >> the "MRN" (if I got this right), but not belong to the same
> >> "COG".  MUAs also belong to one or more MONs / MRNs, but not
> >> necessarily to the same "COG" as the correponding MSA / MDA.
> > 
> > Yup.
> 
> 
> 1. Having the term refer to either origination or reception means we need 
> multiple terms.  I am seeking a single term.

I coined separate terms because I found that I could not clearly
describe the appropriate behavior using a single term.  The
requirements for processing of mail by an origination network are
different than those for a reception network.

When I coined MON and MRN I did so after first trying to refine the
text without defining new terms, and failing to produce something that
seemed sufficiently clear or precise.   Of course, someone else might
have better skill.

> 2. Having the termr efer to either origination or reception ignores transit 
> operations.  The term needs to cover those activities, too.

I haven't seen a need to include transit operations in either case, and
to me it seems like that would make it muddier.  The whole assumption
behind discouraging third-party relaying is that a mail network should
only process messages that were either originated from within that
network, or intended for a recipient within that network.  This 
implies that "transit" operations - which I take to mean a relay by an
MTA that has no relationship with either the originator or the
recipient - are discouraged. 

Even when mail handling is "outsourced", it must still follow rules
appropriate to the role it is performing - whether it is relaying the
mail on the originator's behalf (because it has an arrangement with the
originator) or on the recipient's behalf (because it has an arrangement
with the recipient).  If the network isn't relaying the mail on the
behalf of either party, that's third-party relaying.   Even when the
same mail network provides service to both the sender and recipient,
it's important to implement sender and recipient policies in the right
order.  If the sender (or sender's domain) requires that outgoing mail
be authenticated,  it doesn' t matter whether the recipient is handled
by that mail network or not - the submission should still be rejected.
Similarly, if the recipient (or recipient's domain) has a policy of
rejecting mail according to certain criteria, the fact that the message
was sent from within the same network is irrelevant, because if both  -
the message should still be rejected.

> 3.  Whether an outsourced activity falls under the administrative policies 
> of the client or the operator is an interesting question, and not one with 
> an obvious answer.  So the common term needs to permit either answer.

Or perhaps trying to describe both behaviors using only one set of
terms obscures an answer that would otherwise be obvious.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Stewart Bryant]

Bob Braden wrote:

  *> 
  *> Bob Braden wrote:
  *> 
  *> >   *>  
  *> >   *> > It just struck me as odd that people were grousing about ASCII's
  *> >   *> appearance when PDF is available.  
  *> >   *> 
  *> >   *> People will stop complaining when the ASCII version is allowed to sa

  *> >   *> "see diagram in the PDF version".
  *> >   *> 
  *> >   *> Y(J)S
  *> >   *> 
  *> > 
  *> > Huh?  That has always been allowed.  What am I missing?
  *> 
  *> Please can we be quite clear on this - for the record:
  *> 
  *> I can include a normative diagram in the .pdf version of an RFC

  *> (that is too complex to produce in ASCII art), and say in the
  *> normative text of the ASCII version the diagram you need to
  *> implement this protocol is in the .pdf version of this RFC?

No, the .ps/.pdf is not allowed to be normative.



Which is the point that I was making and Yaakov summarized
so succinctly.

We need to change the publication process so that we can move away
from 1960's improvisations to clear diagrams using modern
techniques. Anything less leaves us without the ability to
describe protocols using the clearest methods currently
available.

- Stewart



Bob Braden




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[kent crispin]

On Mon, Nov 14, 2005 at 09:27:46PM +, Stewart Bryant wrote:
> We need to change the publication process so that we can move away
> from 1960's improvisations to clear diagrams using modern
> techniques. Anything less leaves us without the ability to
> describe protocols using the clearest methods currently
> available.

The clearest methods currently available might include visio diagrams or
powerpoint slides -- at least according to some people. 

-- 
Kent Crispin 
[EMAIL PROTECTED]p: +1 310 823 9358  f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Randy.Dunlap]

On Mon, 14 Nov 2005, kent crispin wrote:

> On Mon, Nov 14, 2005 at 09:27:46PM +, Stewart Bryant wrote:
> > We need to change the publication process so that we can move away
> > from 1960's improvisations to clear diagrams using modern
> > techniques. Anything less leaves us without the ability to
> > describe protocols using the clearest methods currently
> > available.
>
> The clearest methods currently available might include visio diagrams or
> powerpoint slides -- at least according to some people.

SVG was mentioned (as spec'd by w3.org IIRC).

So check out Inkscape:
  "using the  W3C standard Scalable Vector Graphics  (SVG) file format."

Available for multiple platforms.

  http://www.inkscape.org/

-- 
~Randy

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: email "Common Operating Group"

[Tony Finch]

On Mon, 14 Nov 2005, Keith Moore wrote:
>
> I haven't seen a need to include transit operations in either case, and
> to me it seems like that would make it muddier.  The whole assumption
> behind discouraging third-party relaying is that a mail network should
> only process messages that were either originated from within that
> network, or intended for a recipient within that network.  This
> implies that "transit" operations - which I take to mean a relay by an
> MTA that has no relationship with either the originator or the
> recipient - are discouraged.

I think by "transit operations" Dave means things like alias-forwarding
and mailing list explosion.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Joe Touch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Stewart Bryant wrote:
...
> We need to change the publication process so that we can move away
> from 1960's improvisations to clear diagrams using modern
> techniques. 

XML is modern? Where's the modern, WYSIWYG, outline-mode capable editor?
And does one exist that's free?

(I'd love to work in XML, but it seems like a 20-yr step backwards to
manually edit the source code of a document)

Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDeRRCE5f5cImnZrsRAmlGAJ0SZjcsvK7lR4JVOBe+dw/JtyEAwACeOT5C
RKNzILPK1F0AEXT/33ot2o4=
=cCOp
-END PGP SIGNATURE-

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: email "Common Operating Group"

[Dave Crocker]

I think by "transit operations" Dave means things like alias-forwarding
and mailing list explosion.


Yea, as well as such scenarios as an organization that has MUAs, and an MSA, 
and posts all its mail through an ISP's MTA.  The originating organization 
and the transit ISP are separate COGs.


d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Joe!

On Mon, 14 Nov 2005, Joe Touch wrote:

> XML is modern? Where's the modern, WYSIWYG, outline-mode capable editor?
> And does one exist that's free?

OpenOffice, XXE, etc.  Google is your friend.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDeRnm8KZibdeR3qURAvinAJwN3Tf2d6qRB/A8VLExE43vlCJogACg6J3w
lejE6UfZ2/tz5w91dOy0x/o=
=kn4h
-END PGP SIGNATURE-


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

On revising 3777 as in draft-klensin-recall-rev-00

[Lakshminath Dondeti]

To give some context:

3777 says that Recall petitions must be signed by 20 people who are 
eligible to be a nomcom voting member.


draft-klensin-recall-rev-00 suggests that this rule "inadvertently" 
disqualifies sitting IAB and IESG members and proposes to allow them 
to sign Recall petitions.


Inadvertent as it may be, I think that the nomcom-qualification is a 
perfectly fine rule, and sets a higher-bar for the recall process 
than the new proposal.  A quick count of the number of IAB and IESG 
seats we have available reveals that IAB and IESG members may get 
into brawls (they go to yearly retreats without us commoners around 
to watch them, and gods only know what happens there! :-)) and may 
choose to initiate a recall process on one or more of the them 
without having to explain what's wrong until the recall committee is 
formed.  As it stands today, 3777 forces recall initiators to find 20 
ordinary folks :-), no more than 2 from a single affiliation and 
convince them that a certain IAB/IESG member needs to be replaced 
before her/his term is up, to start the recall process.


regards,
Lakshminath


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Bill Fenner]

On 11/14/05, Joe Touch <[EMAIL PROTECTED]> wrote:
> Where's the modern, WYSIWYG, outline-mode capable editor?
> And does one exist that's free?

Still a work in progress, but see
http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ .  Outline mode is high
on my todo list (I have one working that only does top-level sections,
but haven't gotten it working showing all sections yet.)

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: email "Common Operating Group"

[Sam Hartman]

> "Dave" == Dave Crocker <[EMAIL PROTECTED]> writes:

Dave> 1. Having the term refer to either origination or reception
Dave> means we need multiple terms.  I am seeking a single term.

Speaking as an individual, I believe that having two terms is
preferable to one, and I like the terms Keith suggested.

I believe the benefits of having the terms for future documents and in
common use significantly outweighs any perceived simplicity in this
document.  However see below: my preference is based on my answer to
#2.


Dave> 2. Having the termr efer to either origination or reception
Dave> ignores transit operations.  The term needs to cover those
Dave> activities, too.

I think Bill makes a convincing argument that this is not the case.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams

[Frank Ellermann]

Bob Braden wrote:

> the .ps/.pdf is not allowed to be normative.

Good.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Anthony G. Atkielski]

Randy.Dunlap writes:

> SVG was mentioned (as spec'd by w3.org IIRC).
>
> So check out Inkscape:
>   "using the  W3C standard Scalable Vector Graphics  (SVG) file format."
>
> Available for multiple platforms.
>
>   http://www.inkscape.org/

Using an open format that requires people to install special free software
is no different than using a proprietary format that requires people
to install special free software.  And if that is to be the case, PDF
is much more widespread than SVG.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Anthony G. Atkielski]

Joe Touch writes:

> XML is modern? Where's the modern, WYSIWYG, outline-mode capable
> editor? And does one exist that's free?

XML is fashionable, not necessarily functional.  There's a difference.

> (I'd love to work in XML, but it seems like a 20-yr step backwards
> to manually edit the source code of a document)

A lot of people don't remember that far back.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Diagrams (Was RFCs should be distributed in XML)

[Anthony G. Atkielski]

Stewart Bryant writes:

> However these are not taken as normative, so you have to
> produce an ASCII equivalent, which fundamentally limits the
> complexity of any normative diagram.

Depends.  If the ASCII document is large enough, in theory you can
represent any monochrome image with an arbitrary degree of accuracy.
If line lengths or number are limited, though, this isn't possible.
Essentially you just make some non-blank ASCII character represent a
dark pixel, and use a blank for a white pixel.  So with 768 lines of
1024 characters each, you can represent a typical video display.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf