Re: Alternative formats for IDs

[Frank Ellermann]

Yaakov Stein wrote:

> Actually, cuneiform on clay tablets and hieroglyphics on
> marble stelai seem to be better than paper if you really
> want your message to last a long time.

Libraries have books that are several hundred years old,
and they have problems with some only sixty years old books
depending on the quality of the paper.  What medium available
since say 1946 do you have in mind for archives ?  PDF/A is
at most one part of _this_ puzzle.  

Maybe we should use RFC 2070, after all it's "ours", and AFAIK
 would be a
nice challenge for validator.w3.org (testing... STRRRIKE... ;-)



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

RE: Alternative formats for IDs

[Yaakov Stein]

Title: Re: Alternative formats for IDs






Oh, one more thing.  The most widely-used 
archival form in use at librariesI've visited has been written or printed 
words on paper.  This form hasmuch going for it -- it can represent any 
character set humans have everused, can contain any diagram, and does not 
require any special software toto view or produce.  
 
[YJS] Actually, cuneiform on clay tablets and 
hieroglyphics on marble stelai
seem to be better than paper if you really want your 
message to last a
long time.
 
 


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

RE: Alternative formats for IDs

[Yaakov Stein]

Title: RE: Alternative formats for IDs






John
 
Thanks for the 
thorough summary
of the cons about using Word.
 
I agree with much of what you say,
and am fully aware that Word is not the ideal 
tool.
 
However, I haven't had the same harrowing 
experiences
that I have seen described here on the 
list.
 
Just for the fun of it I went through a 
dozen
documents on a backup from 7 years ago.
All were perfectly readable, all but one came 
up
on the first try with the correct 
formatting
and figures (some asked if I wished to update 
the
outdated format, to which I answered 
yes).
 
Only one caused any problems. It was a 
multilanguage
document (with two directions) and some of the 
text
jumped off the page in a wierd way. But that text 
wouldn't
have written in ASCII anyway.
 
I have never had a problem opening an old 
file
with an up-to-date version of the SW. The 
problems
arise when you try to do the reverse. That makes 
sense
of course, since if you could do everything with 
the
old version, then no-one would buy the new 
one.
After all, a company with 95% 
market has to be inventive 
in order to continue selling.
 
Y(J)S
 


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

RE: Alternative formats for IDs

[Yaakov Stein]

Title: Re: Alternative formats for IDs






> If you do not know how to do that with Word, there is help to 
get.Yes, in RFC 3285.3285 Using Microsoft Word to create 
Internet Drafts and RFCs. M. Gahrns, T. Hain. May 
2002. (Format: TXT=34556 bytes) (Status: 
INFORMATIONAL)[YJS] Yes of course we all have used that.
 
However, unfortunately there are problems with that route
and no-one is supporting it (as XML2RFC is supported). 
 
For example, when printing directly from Word (rather
than first producing the ASCII and then printing)
the margins are all wrong.
 
Also, certain combinations of characters I use in ASCII art
cause (for some unknown and undocumented reason)
strange unprintable characters to appear in the ASCII 
version.
 
In the past I have reported problems to the authors of the 
RFC,
who responded but obviously did not have the time
to look into the specifics.
 
I also tried the TeX tools. I am a TeX fanatic and have 
written countless articles and two large books in TeX,
including my own styles and "low level" programming.
 
The LaTeX style is not very good and also apparently
unsupported. The several dvi2txt tools I tried all had bugs.
I was going to hack up something myself, but then was scared
off by my own experiences, realizing that if I started I 
would
have to support the thing for the rest of my mortal life.
 
So I returned to XML except for cooperative drafts.
And I suffer. But at  least when I contribute to 
 ITU, MFA,
MEF, ETSI, etc I don't have to shop around.
I simply use the editor already installed on my
computer.
 
Y(J)S
 


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

RE: objection to proposed change to "consensus"

[Yaakov Stein]

Title: RE: objection to proposed change to "consensus"






>   However, the text objected to in this 
case argues thatthis process should be extended by a process of counting 
thepeople who don't publicly participate in the discussion, eitherway, 
as having tacitly given their approval to whatever side ofthe argument the 
authors, the WG chairs or the IESG choose.Wow, did we say all 
that?
 
All we are saying is that for the issue we are 
discussing
there is no WG. The only list that is open to its 
discussion 
is the general list, where there is no 
support.
 
However, quite a large number of people who actively 
participate
in IETF WGs (people who are interested in working 
on technical topics, 
but not on the internal workings of the IETF) who want 
the process
changed.
 
We proposed gauging interest by a show of hands at a 
plenary
meeting, rather than by the number of yes votes on 
this list.
Yes, even that is not optimal since there are people 
who prefer
working in the terminal room or touring in the 
evenings,
but it certainly seems to be a better way of finding 
out what
MOST IETF participants want than only reading this 
list.
 
I fail to see how this is equivalent to allowing 
authors or chairs 
to decide for themselves what 
should be done.
 
Y(J)S
 


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

Re: Alternative formats for IDs

[Julian Reschke]

Stephane Bortzmeyer wrote:

If we use a XML format, why the very large and complexe (700 pages)
OpenDocument and not "our" RFC 2629?


Indeed. Although, at some point of time we'll have also to realize that 
there most people when they say "RFC2629" they really mean RFC2629bis. 
So, sooner or later, we'll have to start work on a proper spec revision.


Best regards, Julian

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

Re: bozoproofing DKIM concerns

[John Levine]

> if something like DKIM is successful, I would expect an equilibrium
> where filters are set extremely high and nearly all good senders
> authenticate their messages because otherwise they stand an
> unacceptably high chance of having them rejected.

That seems plausible at some point, maybe five years or more from now,
if DKIM catches on and something doesn't blindside us from left field
in the meantime.

Does anyone consider it to be a problem?

R's,
John



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

Re: objection to proposed change to "consensus"

[Spencer Dawkins]

Brian,

Yours is sort of a general reply to a question which has
very specific relevance in this case.

Yes, the current process allows for getting around a few
nay-sayers.

However, the text objected to in this case argues that
this process should be extended by a process of counting the
people who don't publicly participate in the discussion, either
way, as having tacitly given their approval to whatever side of
the argument the authors, the WG chairs or the IESG choose.


... and this was what concerned me, too.

It's been a couple of years, but we had some discussions are part of the 
IETF Problem Statement about people who aren't comfortable commenting in 
public on technical issues for a variety of reasons (including, but not 
limited to, cultural reasons). The context at that time was people who DO 
comment - just not on public mailing lists.


The guidance we ended up with was that we don't know how to make 
"commenting, just not publically" part of the consensus determination.


In this context, the question is about the IETF toolset, not about protocol 
specifics, but since we insist on using the protocol 
specification/standardization BCPs for process discussions, I'm really 
concerned about asking the IESG to violate those BCPs in determining 
consensus on a process question. It's a slippery slope to "We know what 
consensus is on this protocol question, even if the people who agree don't 
post"...


Spencer

Spencer

Spencer 



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

Re: Alternative formats for IDs

[Stephane Bortzmeyer]

On Wed, Jan 04, 2006 at 03:16:18PM -0500,
 Scott Kitterman <[EMAIL PROTECTED]> wrote 
 a message of 18 lines which said:

> I've been following this thread and I'm a bit surprised that no one
> has suggested Open Document Format:

If we use a XML format, why the very large and complexe (700 pages)
OpenDocument and not "our" RFC 2629?
 

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

Re: Alternative formats for IDs

[Stephane Bortzmeyer]

On Wed, Jan 04, 2006 at 06:50:02PM +0100,
 Lars-Erik Jonsson (LU/EAB) <[EMAIL PROTECTED]> wrote 
 a message of 28 lines which said:

> If you do not know how to do that with Word, there is help to get.

Yes, in RFC 3285.

3285 Using Microsoft Word to create Internet Drafts and RFCs. M.
 Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Status:
 INFORMATIONAL)

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

Re: Alternative formats for IDs

[Scott Kitterman]

I've been following this thread and I'm a bit surprised that no one has 
suggested Open Document Format:

http://www.oasis-open.org/committees/office/faq.php

Although it's still pretty new, it is fully documented, useable by editors 
available on multiple platforms, and appears to be free of any significant 
encumbrances.  

It's probably premature to condider this today, but I don't imagine that the 
alternative format discussion is going to resolve itself anytime soon.  

Scott Kitterman

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

Re: bozoproofing the net, was The Value of Reputation

[Michael Thomas]

Harald Tveit Alvestrand wrote:
[]

Sigh. Can I suggest that a little exponential backoff on
all parts may be appropriate? As one of the authors of the
dkim draft, this has been an extremely painful thread to
watch.

Mike

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

Likely DKIM endgame

[Dave Crocker]

Eric,



No, I don't have any empirical evidence for asserting that it's
certain or likely to occur. But in truth nobody has much empirical
evidence for anything here, so we're reduced to theorizing.


Serious theorizing works carefully from an empirical base, with a clear logic 
sequence.  This never guarantees that they are correct, but does serve to vet 
their legitimacy.


Theorizing absent this kind of effort is not theorizing.  It is fantasizing.

There are an infinite number of possible fantasies and their injection into a 
project management effort, such as the start of a standards process, mostly -- I 
even suspect exclusively -- serves as distraction, particularly when they are 
repeated forcefully.




Now that we've got that out of the way, it's worth working through the
reasoning of why I think (b) is the likely endgame.  


It certainly is.



The basic value proposition of any sender authentication system as an
input to filtering is that lets you increase the sensitivity of the
filters, while still obtaining an acceptable overall false positive
rate.


Nicely said.  (And, by the way, I agree with the statement.)


 Imagine that without sender auth, your filters have a false

positive rate of P and a false negative rate of N. With sender auth,
some fraction of those false positives will be eliminated, letting you
dial up the sensitivity of the filter. If we assume that the sender
authentication is perfect, then we get the following:

  Message 
  Authenticated
 
  Yes   No
False positive0 P' (P' > P)  
False negatives   0 N' (N' < N)



But this makes it even more attractive for the good senders to
authenticate their messages (because otherwise they stand a higher
chance of being rejected) which means that the receivers can increase
the sensitivity of their filters, and so on. 

> So, at the end of the

day, if something like DKIM is successful, I would expect an
equilibrium where filters are set extremely high and nearly all good
senders authenticate their messages because otherwise they stand
an unacceptably high chance of having them rejected.


I am less certain of "expect" than I am of "hope for".

In any event, that is quite different from *requiring* everyone to sign, or 
automatically rejecting all unsigned mail.  Yet these are what you were putting 
forward.


Further as was pointed out at the BOF, the scenario you have describe is a 
voluntary community collaboration.  So if the outcome you describe occurs, it 
will be because the community agrees that they like that outcome.


This makes it really perplexing to view it as a problem.


d/
--

Dave Crocker
Brandenburg InternetWorking


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

Re: Likely DKIM endgame

[Eric Rescorla]

Dave Crocker <[EMAIL PROTECTED]> writes:
>> The basic value proposition of any sender authentication system as an
>> input to filtering is that lets you increase the sensitivity of the
>> filters, while still obtaining an acceptable overall false positive
>> rate.
>
> Nicely said.  (And, by the way, I agree with the statement.)
>
>
>   Imagine that without sender auth, your filters have a false
>> positive rate of P and a false negative rate of N. With sender auth,
>> some fraction of those false positives will be eliminated, letting you
>> dial up the sensitivity of the filter. If we assume that the sender
>> authentication is perfect, then we get the following:
>>   Message   Authenticated
>>Yes   NoFalse
>> positive0 P' (P' > P)  False negatives   0
>> N' (N' < N)
>> But this makes it even more attractive for the good senders to
>> authenticate their messages (because otherwise they stand a higher
>> chance of being rejected) which means that the receivers can increase
>> the sensitivity of their filters, and so on.
>  > So, at the end of the
>> day, if something like DKIM is successful, I would expect an
>> equilibrium where filters are set extremely high and nearly all good
>> senders authenticate their messages because otherwise they stand
>> an unacceptably high chance of having them rejected.
>
> I am less certain of "expect" than I am of "hope for".
>
> In any event, that is quite different from *requiring* everyone to
> sign, or automatically rejecting all unsigned mail.  Yet these are
> what you were putting forward.

I don't know what you mean by "putting forward". Here's what I wrote:

   AS I understand it the concern is that people who don't use DKIM
   will eventually not be able to send e-mail to people who are using
   it. I'm not sure that this is something that people should be
   concerned about, indeed, the logic of this kind of system is that
   if it succeeds that's exactly what will happen.

I guess it depends on how significant you think the difference between
"automatically rejecting all unsigned e-mail" and "unacceptably high
chance of having them rejected" is. My view is that it's more a
difference of degree than kind, but I apologize for speaking
imprecisely.


> Further as was pointed out at the BOF, the scenario you have describe
> is a voluntary community collaboration.  So if the outcome you
> describe occurs, it will be because the community agrees that they
> like that outcome.
>
> This makes it really perplexing to view it as a problem.

And I didn't say it was a problem. Indeed, I said "I'm not sure that
this is something that people should be concerned about..."


-Ekr


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

Re: bozoproofing DKIM concerns

[Douglas Otis]

On Jan 4, 2006, at 9:59 AM, Dave Crocker wrote:


E> AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using  
it. I'm not sure that this is something that people should be  
concerned about, indeed, the logic of this kind of system is that  
if it succeeds that's exactly what will happen.



Interesting.

I have not heard any DKIM proponent use that logic.

I have, however, heard critics fail to understand the difference  
between


   a) special handling of "good" identities, versus continuing to  
have suspicious handling of "unknown" identities, and


   b) acceptance of good addresses and rejection of unknown.



The current proposed charter includes both the DKIM signature element  
that indeed provides a stable identifier.  No additional problem  
should be created as a result of this more stable identifier of which  
I can foresee.


There is also a proposal to introduce an email-address authorization  
scheme that transposes the Sender-ID email-addresses with signatures  
and uses a far more disruptive From header rather than the less  
disruptive PRA.  Will there be a PRA proposal for the SSP header  
selection soon?


The concern with this authorization scheme is that many email-address  
domains will likely be coerced into publishing some form of  
authorization to mitigate the high overhead otherwise imposed by the  
scheme.  The next possible point of coercion would be to restrict  
authorization to a limited set of signatures which dramatically  
alters current practices and is inherently unfair.  In general, when  
this authorization is used to accrue reputation as was done with  
Sender-ID, this imposes an unfair and highly disruptive element into  
how email functions.




Proponents seek to use DKIM for a), not b).


This mischaracterizes the concern raised significantly.



Critics keep asserting that b) is the only avenue that is possible.



Reputation based upon some identifier is already ubiquitously used to  
block abusive email.  A stronger method of identification does not  
increase any concern related to 'b' except when applied to the SSP  
authorization instead of the signature.  Even the SSP draft holds the  
email-address domain that provided the authorization accountable by  
way of complaints.  The authorization scheme introduces a weaker and  
unfair method of identification.



So, they are wrong that it is the intent and they have no empirical  
basis for asserting that it is certain or even likely to occur.


There has already been a scheme implemented a major vender that uses  
authorization as suggested.  A minor tweak to widely deploy system  
and instant problem.


-Doug


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

Re: bozoproofing DKIM concerns

[Eric Rescorla]

Dave Crocker <[EMAIL PROTECTED]> writes:

> E> AS I understand it the concern is that people who don't use DKIM
>> will eventually not be able to send e-mail to people who are using
>> it. I'm not sure that this is something that people should be concerned
>> about, indeed, the logic of this kind of system is that if it succeeds
>> that's exactly what will happen.
>
>
> Interesting.
>
> I have not heard any DKIM proponent use that logic.

Maybe not, but I think that it's the likely endgame.


> I have, however, heard critics fail to understand the difference between
>
> a) special handling of "good" identities, versus continuing to
> have suspicious handling of "unknown" identities, and
>
> b) acceptance of good addresses and rejection of unknown.
>
> Proponents seek to use DKIM for a), not b).
>
> Critics keep asserting that b) is the only avenue that is possible.
>
> So, they are wrong that it is the intent and they have no empirical
> basis for asserting that it is certain or even likely to occur.

No, I don't have any empirical evidence for asserting that it's
certain or likely to occur. But in truth nobody has much empirical
evidence for anything here, so we're reduced to theorizing.

Now that we've got that out of the way, it's worth working through the
reasoning of why I think (b) is the likely endgame.  

The basic value proposition of any sender authentication system as an
input to filtering is that lets you increase the sensitivity of the
filters, while still obtaining an acceptable overall false positive
rate. Imagine that without sender auth, your filters have a false
positive rate of P and a false negative rate of N. With sender auth,
some fraction of those false positives will be eliminated, letting you
dial up the sensitivity of the filter. If we assume that the sender
authentication is perfect, then we get the following:

  Message 
  Authenticated
 
  Yes   No
False positive0 P' (P' > P)  
False negatives   0 N' (N' < N)


But this makes it even more attractive for the good senders to
authenticate their messages (because otherwise they stand a higher
chance of being rejected) which means that the receivers can increase
the sensitivity of their filters, and so on.  So, at the end of the
day, if something like DKIM is successful, I would expect an
equilibrium where filters are set extremely high and nearly all good
senders authenticate their messages because otherwise they stand
an unacceptably high chance of having them rejected.

-Ekr



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

Re: Alternative formats for IDs

[Theodore Ts'o]

On Wed, Jan 04, 2006 at 12:45:40PM -0500, Gray, Eric wrote:
> Ted,
> 
>   If that happens, don't you think that we would be
> obliged to object to their claims?
> 
>   IMO, such claims would be easily defeated on the 
> same basis as most "look & feel" claims have been beaten
> in the past.  In fact, I am not aware of issues with any
> sort of rights assertion relative to existing converters
> for MS (or Adobe) document formats.

It is my understanding that Microsoft have been granted one or more
patents relating to their use of XML in their new, incompatible MS
Office document formats that will be used in their upcoming MS Office
release, such that writing programs which manipulate said propietary
XML schemas may require patent licenses.

Whether or not such patent claims are bogus or not, and whether or not
the US Patent Office has their heads in some very dark orifice is
somewhat out of scope of this mailing list, I think.  I just wanted to
warn people that there may be some patent issues relating to working
with the new MS Office XML formats.  And while the Microsoft has
offered some "free" patent licenses for their patents, said patent
rights are not sublicensable, so each end user who wants to use a
converter would have to go on bended knee to Microsoft and request
their own individual patent license.

This should be a very strong argument to not touch the new MS Word
document formats with a ten foot pole, IMHO.

- Ted

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

bozoproofing DKIM concerns

[Dave Crocker]

E> AS I understand it the concern is that people who don't use DKIM

will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be concerned
about, indeed, the logic of this kind of system is that if it succeeds
that's exactly what will happen. 



Interesting.

I have not heard any DKIM proponent use that logic.

I have, however, heard critics fail to understand the difference between

   a) special handling of "good" identities, versus continuing to have 
suspicious handling of "unknown" identities, and


   b) acceptance of good addresses and rejection of unknown.

Proponents seek to use DKIM for a), not b).

Critics keep asserting that b) is the only avenue that is possible.

So, they are wrong that it is the intent and they have no empirical basis for 
asserting that it is certain or even likely to occur.


d/


--

Dave Crocker
Brandenburg InternetWorking


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

RE: Alternative formats for IDs

[Gray, Eric]

Yaakov,

Yes, that would be most of what I meant by "publicly 
available."   Since we're trying to be very precise, I also
include the notion of "readily available documentation" in
the broader concept to "publicly available" where "readily"
may be implied in your use of "open" - and essentially means
that I can get a copy without signing another mortgage.

--
Eric

--> -Original Message-
--> From: Yaakov Stein [mailto:[EMAIL PROTECTED] 
--> Sent: Wednesday, January 04, 2006 1:15 AM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: RE: Alternative formats for IDs
--> 
-->  
--> 
--> > Clarifying that "publicly known" means "well defined and publicly
--> available", I would answer no...
--> 
--> and if it is restricted to mean 
-->   "open description so that you could write your own editor 
--> to read and
--> write this format" ?
--> 
--> 

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

RE: Alternative formats for IDs

[Lars-Erik Jonsson \(LU/EAB\)]

> I don't see why the editor you use needs to be open-standard.
> As far as I know the IETF is attempting to standardize IP-related
> communications protocols, not editors.

Anyone should be able to contribute to the IETF, not just those
who work for big companies who have been fooled into using the
expensive and unstable application environments from M$.


> More seriously, Word is the only commonly used editor
> with an integrated tracking mechanism. I assume that even
> the purists who insist on nroff occasionally write an ID
> with others. I personally prefer to use TeX as a typesetting
> format when writing on my own, but use word for IDs
> since I have to cooperate with co-authors.

Sure, and you are free to do so. Every IETF document editor can
choose his preferred editing tool, as long as it can generate
the basic official ASCII output. If you do not know how to do
that with Word, there is help to get.

BR
/L-E

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

RE: Alternative formats for IDs

[Gray, Eric]

Ted,

If that happens, don't you think that we would be
obliged to object to their claims?

IMO, such claims would be easily defeated on the 
same basis as most "look & feel" claims have been beaten
in the past.  In fact, I am not aware of issues with any
sort of rights assertion relative to existing converters
for MS (or Adobe) document formats.

--
Eric 

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
--> On Behalf Of Theodore Ts'o
--> Sent: Wednesday, January 04, 2006 12:03 PM
--> To: John C Klensin
--> Cc: ietf@ietf.org
--> Subject: Re: Alternative formats for IDs
--> 
--> On Tue, Jan 03, 2006 at 02:59:34PM -0500, John C Klensin wrote:
--> >   (2) Development of a converter between the MS-XML output
--> >   of Word Pro 2003 and the XML input of RFC 2629bis so
--> >   that xml2rfc and its friends could take responsibility
--> >   for final formatting.  Note that, if the converter were
--> >   two-way, you could edit happily in Word and others could
--> >   edit happily in XML and both could interwork.  However,
--> >   as with the above, I think this solution would rapidly
--> >   deteriorate into uselessness unless there were a
--> >   commitment to produce new versions as new versions of
--> >   Office appeared -- at least until Microsoft stabilizes
--> >   and documents their XML formats.
--> 
--> And even when Microsoft stablizes their XML formats, each person who
--> wants to use the converter will have to apply individually to
--> Microsoft for a patent license, for which Microsoft has apparently
--> reserved the right to deny in the future for any reason.  Sweet
--> 
--> - Ted
--> 
--> ___
--> 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: Alternative formats for IDs

[Lars-Erik Jonsson \(LU/EAB\)]

> I do believe that, if you want to do initial document
> preparation in Word, you should be able to do that.  As others
> have suggested, no one I know of is really interested in
> standardizing on or requiring a particular editor.  But, to do
> so, you need to be able to produce an editable format that is no
> worse than ASCII.  You may have better ideas, but, as I have
> explored that range of options, I've come to the conclusion that
> there ought to be two ways to accomplish that end.  They are:
> 
>   (1) Development of an "IETF printer driver" that can be
>   distributed as freeware or with minimal costs and
>   restrictions and that would produce lines and pages of
>   the right layouts _and_ would handle "smart character"
>   to ASCII conversions, generation of appropriate
>   line-ending sequences, etc.  Whomever developed this
>   thing would need to make a long-term commitment to
>   producing and maintaining versions for every version of
>   Windows from, I think, Win98 through the indefinite
>   future.  The generic printer and the conventions of RFC
>   3285 are demonstrably not good enough.

A completely correct observation:
Since the draft-stage of RFC 3285, I have been using MS-Word
as editing tool, and appreciated the WYSIWYG and tracking
advantages of it. However, since the output of the M$ generic
printer driver has changed for *EACH* version of Windows,
I have had to update the parser each time I wanted to support
a new Windows variant, I now have one parser for NT4, one for
98, one for 2000, one for XP, and I even had to improve the
XP version to work properly with Office 2003 under 2000. 

This could be done, and it only affected me who decided to
still use Word as my editing tool. I still believe Word may
be a proper choice for draft editors, but they should be
aware of the problems, and Word is for sure not a proper
format for publishing documents.

/L-E

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

RE: objection to proposed change to "consensus"

[Gray, Eric]

Brian,

Yours is sort of a general reply to a question which has 
very specific relevance in this case.

Yes, the current process allows for getting around a few
nay-sayers.

However, the text objected to in this case argues that 
this process should be extended by a process of counting the 
people who don't publicly participate in the discussion, either 
way, as having tacitly given their approval to whatever side of 
the argument the authors, the WG chairs or the IESG choose.

If we suppose that this might be the ongoing model for
determining consensus, it will never be necessary for anyone
other than the authors, WG chairs and IESG to agree on some
choice to declare consensus - even if the proposal is the most
ghastly nonsense to ever see the light of day - since it will 
always be the case that the majority of people lurking on the 
mailing list will not actively participate in list discussion.

The text argues for this extreme interpretation of the 
current process - where the proponents of an idea consist almost
entirely of its authors, and they need only get the IESG behind
it to make it happen.  I've seen this done once before, where a
WG chair and AD jointly declared consensus against a continuous
stream of objections.  It wasn't pretty then, and it wouldn't be
pretty now.

--
Eric

--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
--> On Behalf Of Brian E Carpenter
--> Sent: Wednesday, January 04, 2006 11:02 AM
--> To: Jeffrey Hutzelman
--> Cc: ietf@ietf.org
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> Jeffrey Hutzelman wrote:
--> > 
--> > 
--> > On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn 
--> > <[EMAIL PROTECTED]> wrote:
--> > 
--> >> Hi -
--> >>
--> >> In 
--> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
--> >> section 3 says:
--> >>
--> >> |   Furthermore, the authors propose that the IESG 
--> carefully consider
--> >> |   declaring consensus in support of the change even if 
--> a large number
--> >> |   of 'nays' are posted to the IESG discussion list.
--> >>
--> >> I object to this text, as it might (mis)lead the reader 
--> into thinking
--> >> that the methods for declaring consensus were being modified, 
--> >> particularly
--> >> if this document somehow became a BCP.  To deal with 
--> this issue, I 
--> >> suggest
--> >> the removal of the following material from section 3:
--> > 
--> > 
--> > Agree.  If the authors actually wish to propose a change 
--> to the way 
--> > consensus is determined in the IETF, then they should do so in a 
--> > separate document.  Naturally, like any process change in any 
--> > organization, such a change would have to be made under 
--> the _existing_ 
--> > process before it could take effect.
--> 
--> Speaking for myself, I agree. The whole point of rough 
--> consensus is to
--> leave scope for some nay-sayers, but it's for the WG Chairs 
--> (if relevant)
--> and the IESG to judge whether the number of objections is 
--> significant.
--> That's not going to change any time soon, and certainly not 
--> as a side effect.
--> 
-->  Brian
--> 
--> 
--> ___
--> 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: Alternative formats for IDs

[Lars-Erik Jonsson \(LU/EAB\)]

> Word is of course out of the question since it is proprietary,
> undocumented, and unstable.  I hope we have consensus on that.

I hope so too!

I initially thought the proposal to use M$ Word as an official
format was a joke. The IETF has a tradition of not caring how
our documents are prepared, that is up to the editor, while we
have a simple common format for our working and published
documents. I personally use Word for preparing my drafts, as
Word works well for me when kept in a single environment (and
"at one point" in time). However, based on experience from
trying to get standards documents from other SDOs, I consider
Word completely broken for publishing purposes. It produces
complex files, the format is unstable and not even compatible
with itself, etc. 

Personally, I do not agree ASCII is insufficient. But if others
do I would support taking small steps towards a new format, if
that format is as openly specified, stable, non-proprietary,
and can be expected to be generally readable over time and in
*all* environments.

/L-E

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

Re: Alternative formats for IDs

[Theodore Ts'o]

On Tue, Jan 03, 2006 at 02:59:34PM -0500, John C Klensin wrote:
>   (2) Development of a converter between the MS-XML output
>   of Word Pro 2003 and the XML input of RFC 2629bis so
>   that xml2rfc and its friends could take responsibility
>   for final formatting.  Note that, if the converter were
>   two-way, you could edit happily in Word and others could
>   edit happily in XML and both could interwork.  However,
>   as with the above, I think this solution would rapidly
>   deteriorate into uselessness unless there were a
>   commitment to produce new versions as new versions of
>   Office appeared -- at least until Microsoft stabilizes
>   and documents their XML formats.

And even when Microsoft stablizes their XML formats, each person who
wants to use the converter will have to apply individually to
Microsoft for a patent license, for which Microsoft has apparently
reserved the right to deny in the future for any reason.  Sweet

- Ted

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

Re: objection to proposed change to "consensus"

[Stewart Bryant]

Brian E Carpenter wrote:


Speaking for myself, I agree. The whole point of rough consensus is to
leave scope for some nay-sayers, but it's for the WG Chairs (if relevant)
and the IESG to judge whether the number of objections is significant.


That is what were asking for in this case.

Stewart

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

Re: bozoproofing the net, was The Value of Reputation

[Eric Rescorla]

"John R Levine" <[EMAIL PROTECTED]> writes:

>> OK.  If this is just an assumption and not backed by evidence, I would
>> suspect that outside of the web you see a lot less use of the big CAs.

This is my impression as well. And a fair amount of the reason here
is UI: the browsers are set up to check the server's cert and
the MTAs generally are not.


> Probably true.  And since DKIM has no provision for authorities at all, it
> definitely doesn't use them.

Well, yes and no. DKIM depends for its security on the DNS,
which means that it depends on the security of the DNS.
In order for this to be strong (i.e., cryptographic) security,
the relevant DNS records need to be signed and that means 
that there's a dependency on the DNSSEC roots.


> So remind me, what is the problem with DKIM that we're all supposed to be
> worried about?

AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be concerned
about, indeed, the logic of this kind of system is that if it succeeds
that's exactly what will happen. 

That said, I don't think that the comparison with STARTTLS is particularly
illuminating. While in principle one could use STARTTLS as a measure
to discriminate between classes of senders, in practice it's not used
that way but instead used primarily for confidentiality. However,
DKIM's only real use is to discriminate between classes of senders,
so we do need to expect it to be used that way.

-Ekr

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

Re: Alternative formats for IDs

[Randy.Dunlap]

On Wed, 4 Jan 2006, Julian Reschke wrote:

> Yaakov Stein wrote:
> >
> >
> >> Clarifying that "publicly known" means "well defined and publicly
> > available", I would answer no...
> >
> > and if it is restricted to mean
> >   "open description so that you could write your own editor to read and
> > write this format" ?
>
> ...without having to sign a contract to the owner of the format, being
> able to rely on its stability, and not having to pay for it...?

IOW, no IPR issues, no lawsuits for implementing/using it
or letting others use what someone has written (documentation
or source code) (?)

-- 
~Randy

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

Re: Question about the Neustar logo on www.ietf.org

[Sam Hartman]

John, perhaps the logos on the IETF website are an issue on which we
can agree to let the IAOC decide reasonable policy and apply it.  It
seems like a long discussion here does not advance our goals.
-
--Sam


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

Re: objection to proposed change to "consensus"

[Brian E Carpenter]

Jeffrey Hutzelman wrote:



On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn 
<[EMAIL PROTECTED]> wrote:



Hi -

In http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
section 3 says:

|   Furthermore, the authors propose that the IESG carefully consider
|   declaring consensus in support of the change even if a large number
|   of 'nays' are posted to the IESG discussion list.

I object to this text, as it might (mis)lead the reader into thinking
that the methods for declaring consensus were being modified, 
particularly
if this document somehow became a BCP.  To deal with this issue, I 
suggest

the removal of the following material from section 3:



Agree.  If the authors actually wish to propose a change to the way 
consensus is determined in the IETF, then they should do so in a 
separate document.  Naturally, like any process change in any 
organization, such a change would have to be made under the _existing_ 
process before it could take effect.


Speaking for myself, I agree. The whole point of rough consensus is to
leave scope for some nay-sayers, but it's for the WG Chairs (if relevant)
and the IESG to judge whether the number of objections is significant.
That's not going to change any time soon, and certainly not as a side effect.

Brian


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

Re: WG Review: EAP Method Update (emu)

[Sam Hartman]

> "Clint" == Clint Chaplin <[EMAIL PROTECTED]> writes:

Clint> Has an email list been set up for this effort yet?
Clint> On 12/22/05, Pekka Savola <[EMAIL PROTECTED]> wrote:


So, pre-wg this is being discussed on [EMAIL PROTECTED]

However the WG will get its own mailing list if approved.


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

Re: bozoproofing the net, was The Value of Reputation

[Tony Finch]

On Wed, 4 Jan 2006, Sam Hartman wrote:
>
> OK.  If this is just an assumption and not backed by evidence, I would
> suspect that outside of the web you see a lot less use of the big CAs.

Web-style TLS is used for authenticating the server in other protocols
too, such as IMAP, submission-mode SMTP, XMPP, etc. etc. and in all these
cases it is extremely desirable not to have to set up a local CA because
the user interface for configuring client software is so bad.

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: bozoproofing the net, was The Value of Reputation

[Harald Tveit Alvestrand]

--On onsdag, januar 04, 2006 09:54:56 -0500 Sam Hartman 
<[EMAIL PROTECTED]> wrote:



John> And the TLS world is dominated by a single signer whose
John> signing policies are opaque.

Really?  Are you sure the TLS world is not dominated by users clicking
OK trust this cert for anything they see, combined with a lot of self
signed certs and certs from a variety of CAs?  I do expect that most
web sites tend to have Verisign certs, but I have no idea about other
uses of TLS.


Here's an interesting thing you can do if you're an Opera user:

Go into the preferences/advanced/security section and mark all your root 
certs as "warn me before I use this cert".
Then Opera will tell you which root cert the website got its cert from 
every time you click on a HTTPS link.


If most of the Net uses Verisign, Verisign's got a bewildering array of 
names




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

Re: bozoproofing the net, was The Value of Reputation

[John R Levine]

> OK.  If this is just an assumption and not backed by evidence, I would
> suspect that outside of the web you see a lot less use of the big CAs.

Probably true.  And since DKIM has no provision for authorities at all, it
definitely doesn't use them.

So remind me, what is the problem with DKIM that we're all supposed to be
worried about?

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

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

Re: bozoproofing the net, was The Value of Reputation

[Sam Hartman]

> "John" == John R Levine <[EMAIL PROTECTED]> writes:

John> The CAs that people use in web SSL are overwhelmingly signed
John> by Verisign or its subsidiaries like Thawte.  Geotrust is a
John> distant second.

John> I honestly don't know what signers people use for STARTTLS
John> but since everyone uses the same small set of TLS libraries,
John> my working assumption is that they use the same small set of
John> authorities, too.

OK.  If this is just an assumption and not backed by evidence, I would
suspect that outside of the web you see a lot less use of the big CAs.


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

Re: bozoproofing the net, was The Value of Reputation

[John R Levine]

> John> Here's a concrete suggestion: it is clear that the bad uses
> John> of DKIM people have mentioned are a subset of the bad uses
> John> of STARTTLS.
>
> That's not clear to me.
> I'd never really considered the question though so it may well be true.

If walled gardens are the problem or the goal, STARTTLS is a swell way to
do it.

> John> And the TLS world is dominated by a single signer whose
> John> signing policies are opaque.
>
> Really?  Are you sure the TLS world is not dominated by users clicking
> OK trust this cert for anything they see, combined with a lot of self
> signed certs and certs from a variety of CAs?

The CAs that people use in web SSL are overwhelmingly signed by Verisign
or its subsidiaries like Thawte.  Geotrust is a distant second.

I honestly don't know what signers people use for STARTTLS but since
everyone uses the same small set of TLS libraries, my working assumption
is that they use the same small set of authorities, too.

> John> So how about if we simply reuse the warning language about
> John> STARTTLS from RFC 3207?
>
> What warning language?  I can't find anything related to this problem.
> I may not be looking carefully enough.

There isn't any.  That's my point.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

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

Re: bozoproofing the net, was The Value of Reputation

[Sam Hartman]

> "John" == John Levine <[EMAIL PROTECTED]> writes:

>> Roughly we need to consider how DKIM is used, not just define a
>> technology.  We need to talk about bad uses of DKIM as soon as
>> we are aware that they are sufficinetly likely that they are
>> worth considering.

John> Here's a concrete suggestion: it is clear that the bad uses
John> of DKIM people have mentioned are a subset of the bad uses
John> of STARTTLS.

That's not clear to me.
I'd never really considered the question though so it may well be true.

John> I have seen concerns that third party reputation lists might
John> be used to create walled gardens or closed networks with
John> DKIM.  This is not just a theoretical risk with STARTTLS.
John> People have already done exactly that, since TLS unlike DKIM
John> already includes the facilities for third parties to
John> indicate which keys they like and which ones they don't.


Interesting I'll admit that I have not run into people who seem to
have a problem with a self-signed starttls cert in practice, although
I might not have noticed.  Also, I don't configure MTAs or my MUA to
offer a client cert, only a server cert.

I agree it is possible and am happy to take your word for it that someone has 
done so.

John> And the TLS world is dominated by a single signer whose
John> signing policies are opaque.

Really?  Are you sure the TLS world is not dominated by users clicking
OK trust this cert for anything they see, combined with a lot of self
signed certs and certs from a variety of CAs?  I do expect that most
web sites tend to have Verisign certs, but I have no idea about other
uses of TLS.

John> So how about if we simply reuse the warning language about
John> STARTTLS from RFC 3207?  

What warning language?  I can't find anything related to this problem.
I may not be looking carefully enough.


John> If that's not adequate, do we need
John> to write similar warnings about STARTTLS?

Quite possibly.


--Sam

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

Re: bozoproofing the net, was The Value of Reputation

[John Levine]

> Roughly we need to consider how DKIM is used, not just define a
> technology.  We need to talk about bad uses of DKIM as soon as we
> are aware that they are sufficinetly likely that they are worth
> considering.

Here's a concrete suggestion: it is clear that the bad uses of DKIM
people have mentioned are a subset of the bad uses of STARTTLS.

I have seen concerns that third party reputation lists might be used
to create walled gardens or closed networks with DKIM.  This is not
just a theoretical risk with STARTTLS.  People have already done
exactly that, since TLS unlike DKIM already includes the facilities
for third parties to indicate which keys they like and which ones they
don't.  And the TLS world is dominated by a single signer whose
signing policies are opaque.

So how about if we simply reuse the warning language about STARTTLS
from RFC 3207?  If that's not adequate, do we need to write similar
warnings about STARTTLS?

R's,
John

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

RE: [Ipsec] Last call comments about "Repeated Authentication in IKEv2"

[Yoav Nir]

Comments inline 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> On Behalf Of [EMAIL PROTECTED]
> 
> 1) Overall: Being able to reauthenticate the client (either
> periodically or by some other trigger) is a common requirement in
> remote access deployments. It's a good idea to have one documented
> way to do this, instead of each vendor inventing its own proprietary
> payloads. Thus, I think this document is a very useful extension to
> IKEv2, and deserves to be published.
> 
> 2) The document could be more precise about in describing what
> messages can contain the AUTH_LIFETIME notification. The intent was
> clearly "in the last IKE_AUTH response or in any INFORMATIONAL
> request", but this is not exactly the same as saying "in a separate
> Informational exchange" (which might be interpreted as including
> both the request and response messages) or "MAY be sent by the
> original Responder at any time".

You're right about the former, but I think the latter needs to stay. It
refers to the timing of sending the message.

> 3) Section 2: "It is recommended that an INITIAL-CONTACT
> notification be included in the AUTH exchange." 
> 
> This is probably not correct. RFC4306 says that "This notification
> MUST NOT be sent by an entity that may be replicated (e.g., a
> roaming user's credentials where the user is allowed to connect to
> the corporate firewall from two remote systems at the same time)."
> 
> Even if the corporate IT department has decided not to allow this,
> the initiator probably does not know this, so it should not include
> the notification. 
> 
> Furthermore, the INITIAL_CONTACT notification is not really needed 
> for anything in this case, since the client has not crashed,
> and it still has all the information it needs to properly close 
> the old IKE_SA (once the new one has been established).

I thought INITIAL_CONTACT would be a shorter way to achieve the same goal,
but I forgot about the replication problem. I agree.  This line must go.

> 4) Section 7 (IANA Considerations): The text should say that the
> number needs to be assigned from the "Status Types" range (and not
> the "Error Types" part)

Well, if and when this is published, This would change to a specific,
allocated number.  I did write this in the IANA application.
 
> 5) Typos etc.
> Section 2: the Informational response should be "HDR, SK{}" 
> Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/
> Section 6, should explicitly say that both references are normative

Agreed.


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

Re: WG Review: Domain Keys Identified Mail (dkim)

[Sam Hartman]

I support the new charter and thank those who spent the time
discussing it and walking through alternatives.

--Sam


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

Re: bozoproofing the net, was The Value of Reputation

[Sam Hartman]

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

Dave> John K., et al, Feliz año nuevo; Selamat tahun baru.


>> I do believe that it is not desirable to create standards that
>> would give a gift of either technology or justification to
>> those who would use them to fragment the network.  I believe it
>> is especially

Dave> I suspect we will not find anyone in the IETF who thinks
Dave> otherwise.  Certainly my own reaction to your statement,
Dave> here, was "Yes!!  Absolutely Correct!"

Dave> Then I tried to consider the implications of the statement,
Dave> in the current context, and I realized that I have no idea
Dave> what pragmatic import it has.

Dave> I have no idea how to apply this caveat to the DKIM work.

Dave> DKIM is DKIM. As a technology it has a specific intent and
Dave> its core is well-defined -- and actually pretty simple --
Dave> with well-understood properties. The core is similar to a
Dave> number of technologies that have been in use for at least 15
Dave> years.

I think John is expressing a concern similar to the one I expressed at
the BOF.

Roughly we need to consider how DKIM is used, not just define a
technology.  We need to talk about bad uses of DKIM as soon as we are
aware that they are sufficinetly likely that they are worth
considering.

We need to write BCPs as soon as we are in a position to know what
best practice actually is.

Now, other than acknowledging that we need to eventually do these
things, I don't think this has any impact on the charter.  On the
other hand, John replied to a message about three levels removed from
the charter and proposed no specific changes to the charter.  So I
don't have any evidence that he planned to change the charter either.

--Sam


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

Alternatives to DKIM

[Sam Hartman]

> "william(at)elan" == william(at)elan net <[EMAIL PROTECTED]> writes:
william(at)elan> And yes in case you don't know BoF chairs and AD
william(at)elan> did deny request to present alternatives to DKIM
william(at)elan> when it was still called MASS BoF.


Russ did state an explicit course of action for those with
alternatives to DKIM.  He asked them to get a specific proposal
together and ask for their own BOF.

I don't know what mail Russ has received, but I know that even though
we have had another IETF meeting since that BOF, no requests were
copied to me for other related BOFs.


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

Last call comments about "Repeated Authentication in IKEv2"

[Pasi . Eronen]

1) Overall: Being able to reauthenticate the client (either
periodically or by some other trigger) is a common requirement in
remote access deployments. It's a good idea to have one documented
way to do this, instead of each vendor inventing its own proprietary
payloads. Thus, I think this document is a very useful extension to
IKEv2, and deserves to be published.

2) The document could be more precise about in describing what
messages can contain the AUTH_LIFETIME notification. The intent was
clearly "in the last IKE_AUTH response or in any INFORMATIONAL
request", but this is not exactly the same as saying "in a separate
Informational exchange" (which might be interpreted as including
both the request and response messages) or "MAY be sent by the
original Responder at any time".

3) Section 2: "It is recommended that an INITIAL-CONTACT
notification be included in the AUTH exchange." 

This is probably not correct. RFC4306 says that "This notification
MUST NOT be sent by an entity that may be replicated (e.g., a
roaming user's credentials where the user is allowed to connect to
the corporate firewall from two remote systems at the same time)."

Even if the corporate IT department has decided not to allow this,
the initiator probably does not know this, so it should not include
the notification. 

Furthermore, the INITIAL_CONTACT notification is not really needed 
for anything in this case, since the client has not crashed,
and it still has all the information it needs to properly close 
the old IKE_SA (once the new one has been established).

4) Section 7 (IANA Considerations): The text should say that the
number needs to be assigned from the "Status Types" range (and not
the "Error Types" part)

5) Typos etc.
Section 2: the Informational response should be "HDR, SK{}" 
Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/
Section 6, should explicitly say that both references are normative

Best regards,
Pasi

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

Re: Alternative formats for IDs

[Julian Reschke]

Yaakov Stein wrote:
 


Clarifying that "publicly known" means "well defined and publicly

available", I would answer no...

and if it is restricted to mean 
  "open description so that you could write your own editor to read and

write this format" ?


...without having to sign a contract to the owner of the format, being 
able to rely on its stability, and not having to pay for it...?


Best regards, Julian

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