Re: calendar file for IETF

[Henrik Levkowetz]

On 2005-07-22 18:51 Cyrus Daboo said the following:
[...]
> BTW I think it might be worthwhile for the folks working on tools for IETF 
> processes to look into having an automatic iCalendar generator for IETF 
> agendas as a lot of people now have iCal capable clients that they could 
> use to display the agendas. Another case where we should eat our own dog 
> food!

Agreed.  If Elliot will donate his script, I'll arrange for it to be run
automatically as needed, and the result to be accessible from the
http://tools.ietf.org/ website.


Henrik




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Francois Menard]

On Sat, 23 Jul 2005, Masataka Ohta wrote:


PKI has nothing to do with E2E.
As CAs and DNS servers are intermediate systems, neither PKI nor
DNS are E2E.
As intermediate systems, they don't have any information on
ongoing transaction that they can't give any real guarantee.


Masataka-San, your NOTASIP ID still rings in my mind after all these years 
and I see that your approach at providing consistency to a discussion 
continues to be as thoughtful as it ever has been.


This being said, in my question, I did knowingly imply that PKI as we know 
it from CAs is not end-to-end as CAs are intermediate systems.


In your opinion, what do you see as the latest state of the art thinking 
towards PKI that is true-er to an E2E environment, knowing that I am 
looking for an answer in the context of my need to catch up quick so that 
I can better defend the need for a multiple roots at the NXX level in the 
ENUM environment - my true goal being to tell carriers to screw it with 
Carrier-ENUM.  My argument is that you cannot subdomain a telephone number 
which can remain reachable from a telephone keypad, thus the need for 
competition at the registry level (if not, innovation will be restricted 
by the transaction costs of registering entries in Tier1B).


I have described my proposed Tier1C here in details: 
http://www.crtc.gc.ca/cisc/COMMITTE/C-docs/CNCO0004.doc


If pursuing this discussion gets too wild on IETF-discuss, I will agree to 
defer the ongoing discussion to the E2E-interest mailing list on 
postel.org and refer back once I have a better idea how stable is the 
ground.  However, true here is my ambition to frame the discussion in such 
a way that I can know how to tackle my Tier1C proposed framework into the 
broader perspective of where the IETF has been, where it can go and where 
it does not or no longer wants to go (at least in the short term).


-=Francois=-
819 692 1383

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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[JFC (Jefsey) Morfin]

At 22:54 22/07/2005, Brian E Carpenter wrote:
I wouldn't change a word in RFC 2826.

The problem with RFC 2826 is that it links (for information) a unique 
domain name resolution (what we want) with a unique authoritative root file 
(we do not care it is "unique", we want the one we use to be pertinent). 
Confusing the description with the described space was a way to protect the 
name space, but it unfortunately lead to open roots confusion and to 
alt-root suspicion (I only know one: ICANN with .biz) and to the lack of 
preparation in front to PAD (private roots).


Now, I agree with Stephane and ICANN that a lot is/can to be done. We just 
have to remember IMHO the namespace is the same as geographical space: the 
map does not build the geography and no one thinks that geography depends 
on the map he uses.


Except may be politics.

But there may and is to be a lot of innovative thinking. ICP-3 is 
excellent, starting with a good review of RFC 2826, rooting into RFC 920 
which is the true basis of the DNS as we live it, and calling on 
experimentation and proposing avenues for the research and development with 
classes (the way to the externets).


jfc



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

Re: RTP vs. MIME

[Colin Perkins]

On 22 Jul 2005, at 16:25, Bruce Lilly wrote:
...
To the extent that transport protocol overhead has been erroneously  
included in what is purported to be a media format specification,  
that is a problem with the registration and/or specification.


There is nothing in the MIME rules which requires an RFC to include  
only a MIME registration template. Despite your attempts to claim  
otherwise, it is entirely legitimate and appropriate for an RFC to  
include both a media type registration and some other specification.


And I would add that that causes problems for MIME reviewers and  
implementers, and said problems would be alleviated by a separate  
registry with separate rules, where RTP-specific registrations can  
conflate transport bits with format bits or not without causing  
problems for MIME reviewers and implementers.


The documents clearly separate "transport bits" from "format bits",  
so this is not an issue.  This separation has been repeatedly  
explained to you, and is documented in these particular  
specifications, and the RTP specification (RFC 3550 -- STD 64).



You are confusing the applicability statement which
describes RTP-specific processing with the description of the media
type.


I see nothing in 3267 labeled "applicability statement"; I do see
multiple "format" descriptions.


There is no requirement in RFC 2026 for the explicit label  
"applicability statement" to appear anywhere, so this cannot be your  
complaint. You will find several format descriptions in the RFC: two  
RTP payload formats, and two media types. The two RTP payload format  
definitions (section 4 of RFC 3267) describe how the two media types  
are conveyed within RTP, but don't define the media types. The two  
media types are described in section 5 of RFC 3267, with reference to  
the 3GPP specifications which define the bit patterns and semantics  
of the speech frames. The media type registrations are in section 8  
of RFC 3267. You are, as I previously stated, confusing the RTP  
specific processing (an "RTP Payload Format") with the description of  
the media type.



The formats are specified in the following:

[1]   3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech
transcoding",
  version 4.0.0 (2001-03), 3rd Generation Partnership Project
  (3GPP).

[2]   3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
  4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).

[3]   3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
  functions", version 5.0.0 (2001-03), 3rd Generation
Partnership
  Project (3GPP).

[4]   3GPP TS 26.201 "AMR Wideband speech codec; Frame  
Structure",

  version 5.0.0 (2001-03), 3rd Generation Partnership Project
  (3GPP).


26.090, according to http://www.3gpp.org/ftp/Specs/html-info/26090.htm
is "AMR speech Codec; Transcoding Functions".  Transcoding  
functions and

media formats are separate types of specifications.  "Frame structure"
specifications *might* be applicable, *if* the media format is  
identical

to said "frame structure", but I see nothing in the registration form
that says so, and several parts of section 5 imply otherwise; sections
5, 5.1, and 5.2 make no reference to what precisely comprises "speech
frames" or "speech bits" or indeed why two different terms are used.


The 3GPP documents are, without any doubt, both applicable and  
appropriate specifications for these formats.  There are several  
dozen independent and interoperable implementations based on the  
specifications, using the media formats both with RTP and in more  
traditional MIME contexts such as file downloads. These  
implementations are in daily use by tens of millions of users. By any  
measure, this meets the necessary standards of specification clarity  
for the community which is implementing the standard.


That is a very good reason for a separate registry.  There is no  
question that the proposed media type did not meet the  
requirements for registration in the text top-level MIME  
registry; it should never have been proposed to register it  
there.  With a separate RTP registry, those interested in RTP can  
establish whatever rules or lack of rules for things to be  
considered as RTP "text".


You seem to be complaining because we asked the advice of the MIME
community on whether the 3GPP timed text format should be registered
under text or video, and then took that advice. Quite how this can be
construed as a failure of the process, or as a statement that RTP is
not appropriate for use with MIME types is beyond me.


One might as well ask whether or not an elephant is eligible for a dog
license.  The question shouldn't even be asked.  And it wasn't a  
simple

matter of "took that advice", there was argument that even though the
media clearly was incompatible with text, that it should be registered
under text anyway, presumably merely because some RTPers would like it
that way wi

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Masataka Ohta]

Brian E Carpenter wrote:

> Don't forget that
> the uniqueness property of a domain name is used to guarantee uniqueness
> in other, derived, namespaces,

How is it guaranteed? That is, who pays how much if the broken
uniqueness resulted in loss of, say, $1,000,000?

Without proper guarantee, based on the amount of money and risk
of each transaction, PKI (including SDNS) can not be used for
serious security purposes and is merely an overly complex way
for abstract security such as just checking IP addresses
through 3 way handshake.

Masataka Ohta

PS

PKI has nothing to do with E2E.

As CAs and DNS servers are intermediate systems, neither PKI nor
DNS are E2E.

As intermediate systems, they don't have any information on
ongoing transaction that they can't give any real guarantee.


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

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Paul Hoffman]

At 3:51 PM -0400 7/22/05, Bill Sommerfeld wrote:

On Fri, 2005-07-22 at 07:35, Sam Hartman wrote:

 BTW, this conversation and a side conversation with John has convinced
 me that IESG review should involve a call for comments phase.


A call for comments requires having something for the community to
comment on.

Will an internet draft will be required from folks seeking IESG review
of a proposed assignment, or will we invent yet another mechanism for
circulating a description of the proposal to the community?


It would make sense for the IESG to send to the community what was 
sent to them; that way, we can judge what they are judging. If it was 
a pointer to an Internet Draft, great; a pointer to some other 
document(s) works just as well.


--Paul Hoffman, Director
--VPN Consortium

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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Brian E Carpenter]

Stephane Bortzmeyer wrote:

On Fri, Jul 22, 2005 at 10:08:03AM -0400,
 Francois Menard <[EMAIL PROTECTED]> wrote 
 a message of 42 lines which said:


  You, not everybody
  v

I would for example not trust .travel from new.net if ICANN had assumed 
control over .travel ... I should be able to pick this from a PKI-based 
P2P trust chain, would I not?



Since other people would have a different trust chain, this will be a
significant move from the current semantics of the DNS. Today,
"airfrance.travel" is the same for me and for you. With your system,
they may be different.

I do not say that it is good or bad, just that it is a different
system than the one users are accustomed to.



I say it would be very bad. It would create golden opportunities for
fraud and deception, quite apart from immense confusion of the general
public.

[The fact that two versions of the same name were both cryptographically
connected to their respective roots wouldn't in the least prevent
fraud and confusion - it would rather give a fraudulent site a spurious
appearance of authenticity.]

Also, pity the poor computers. Humans might just be able to navigate
in a world of ambiguous names, but computers can't. Don't forget that
the uniqueness property of a domain name is used to guarantee uniqueness
in other, derived, namespaces, so it isn't only the direct use of DNS
that would be broken by ambiguity. XML namespaces would be broken too,
for example.

I wouldn't change a word in RFC 2826.

   Brian


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

Please change the Subject: when you change the subject [Re: Sarcarm and intimidation]

[Brian E Carpenter]

...

Does this mean that you think the IETF should disband the ASRG, drop all
current I-D's relating to spam, and quit working on spam issues?  


What I think is that if you change the subject, you should change
the Subject:, so that people who might be interested in "Sarcarm
and intimidation" but aren't interested in "Spam" don't waste their
time.

   Brian


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

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Bill Sommerfeld]

On Fri, 2005-07-22 at 07:35, Sam Hartman wrote:
> BTW, this conversation and a side conversation with John has convinced
> me that IESG review should involve a call for comments phase.

A call for comments requires having something for the community to
comment on. 

Will an internet draft will be required from folks seeking IESG review
of a proposed assignment, or will we invent yet another mechanism for
circulating a description of the proposal to the community?

- Bill



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

Re: Sarcarm and intimidation

[Dean Anderson]

On Thu, 21 Jul 2005, Noel Chiappa wrote:

> > From: Dean Anderson <[EMAIL PROTECTED]>
> 
> >> Anyway, I hereby propose the IETF Corollary to Godwin's Law: whenever
> >> any IETF thread migrates to the subject of spam, it's time to end the
> >> thread.
> 
> > Does this mean that you think the IETF should disband the ASRG, drop
> > all current I-D's relating to spam, and quit working on spam issues?
> > ... if Chiappa genuinely thinks the IETF should stop spam work, he
> > should say so directly, so as to be clearly understood.
> > .. if the IETF is going to work on spam, then occasionally the main IETF
> > list will have to discuss the issue
> 
> You seem to have missed the word "migrate" in my post.

I see.  I thought you were talking about the current thread, not some
hypothetical migration of some other thread. 

Hallam-Baker started the current thread to complain about sarcasm and
intimidation relating to anti-spam efforts. And there clearly is
intimidation. The current thread did not migrate; hence I mistook your
comments as being somehow relevant to the current thread.

It is too bad you didn't take the opportunity to clear up the ambiguity of
whether you want the IETF to stop work on spam issues.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

Re: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Philip Guenther]

Stephen Sprunk <[EMAIL PROTECTED]> writes:
...
>It's already happening.  There is a large (and growing) number of corporate 
>networks where 802.1x is mandatory -- if you don't do it, you simply can't 
>connect.  I've also run into a fair number that require registering MAC 
>addresses (default is to deny or sandbox) due to vendors who don't yet do 
>802.1x.
>
>End-to-end is a great goal, but it doesn't reflect the real world today. 
>Not that it's an excuse to _require_ middleware in protocols, but we need to 
>design with the knowledge that they _may_ exist.

Maybe I'm just slow, but I fail to see the connection between those two
paragraphs.  How does authentication of network access serve as a
counter example to the end-to-end principle?  As far as I can tell,
they're completely orthogonal, just as e2e isn't refuted by the
existence of DHCP.  Or did I miss a discussion about how DHCP is a
middleware protocol?


Philip Guenther

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

Re: calendar file for IETF

[Eliot Lear]

> 
> Thanks for the file. Unfortunately it is not a valid iCalendar file 
> To fix this, just add the following line below the 'BEGIN:VCALENDAR' line:
> 
> VERSION:2.0

Done!
> 
> In addition, each VEVENT component needs to have a UID property with a
> unique identifier in each one. 

Done!

> Also, I note there is a new updated agenda out that is different from
> the one you posted.

NOT DONE - will work on it tomorrow.

Eliot

> 
> BTW I think it might be worthwhile for the folks working on tools for
> IETF processes to look into having an automatic iCalendar generator for
> IETF agendas as a lot of people now have iCal capable clients that they
> could use to display the agendas. Another case where we should eat our
> own dog food!

AGREE!

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

Re: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Stephen Sprunk]

Thus spake "Stephen Kent" <[EMAIL PROTECTED]>

Boy are you in for a shock when you try to connect to an ethernet with
802.1x.


I have yet to do so. I do have the facility on my Mac, but I've never had 
to turn it on.


You need to get out more.


Authentication is being built into the NIC cards. At some point in the
future it will not be possible for any device to connect to an Intranet
without first authenticating itself.


It could happen, but then too it might not.


It's already happening.  There is a large (and growing) number of corporate 
networks where 802.1x is mandatory -- if you don't do it, you simply can't 
connect.  I've also run into a fair number that require registering MAC 
addresses (default is to deny or sandbox) due to vendors who don't yet do 
802.1x.


End-to-end is a great goal, but it doesn't reflect the real world today. 
Not that it's an excuse to _require_ middleware in protocols, but we need to 
design with the knowledge that they _may_ exist.


S

Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov 



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

Re: calendar file for IETF

[Cyrus Daboo]

Hi Eliot,

--On July 21, 2005 9:23:16 PM +0200 Eliot Lear <[EMAIL PROTECTED]> wrote:


For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics.

I claim no competence in any of this.  No responsibility if you miss
your meetings.  No promises to update it.  But it works for me.


Thanks for the file. Unfortunately it is not a valid iCalendar file as the 
VERSION property is missing. That property is required by the iCalendar 
specification (rfc2445 section 4.6).


To fix this, just add the following line below the 'BEGIN:VCALENDAR' line:

VERSION:2.0

In addition, each VEVENT component needs to have a UID property with a 
unique identifier in each one. Whilst the syntax of section 4.6.1 of 
rfc2446 implies that that parameter is optional, the description for the 
parameter itself (section 4.8.4.7) actually says it MUST be present. The 
Calisfy working group is attempting to fix ambiguities in the spec like 
that, amongst other things.


I did 'fix' my version of the file with suitable changes and was able to 
import it correctly into my client.


Also, I note there is a new updated agenda out that is different from the 
one you posted.


BTW I think it might be worthwhile for the folks working on tools for IETF 
processes to look into having an automatic iCalendar generator for IETF 
agendas as a lot of people now have iCal capable clients that they could 
use to display the agendas. Another case where we should eat our own dog 
food!


--
Cyrus Daboo

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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Paul Hoffman]

At 10:08 AM -0400 7/22/05, Francois Menard wrote:
I would for example not trust .travel from new.net if ICANN had 
assumed control over .travel ... I should be able to pick this from 
a PKI-based P2P trust chain, would I not?


Then you have created a new root, namely a combined one that you have 
hand-crafted yourself. It might not sound like a root, but it truly 
is. With a traditional trust anchor, the people trusting it  also 
trust that the anchor will have unique names beneath it. In your 
proposal, you start with a group of trust anchors, and you 
hand-select where there are name conflicts of names beneath two of 
the anchors. In doing so, you elevate yourself to being root, and you 
hide the existence of the trust anchors in your new personal 
hierarchy.


At 4:16 PM +0200 7/22/05, Stephane Bortzmeyer wrote:

Since other people would have a different trust chain, this will be a
significant move from the current semantics of the DNS.


Exactly right. In the current DNS, there is essentially no one saying 
"Trust Anchor A and Trust Anchor B differ on who are the name servers 
for .travel, so I'm going to pick the ones from Trust Anchor A." 
(FWIW, .travel just appeared in the root zone yesterday.)



I do not say that it is good or bad, just that it is a different
system than the one users are accustomed to.


Well, because it is both quite different than what we have today, and 
it would be really difficult to explain to the vast majority of 
internet users, I would say it would be "bad" to introduce it now. A 
similar model would be fine in other contexts, but not the DNS or the 
IP address space.


--Paul Hoffman, Director
--VPN Consortium

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

Re: RTP vs. MIME

[Bruce Lilly]

>  Date: 2005-07-20 16:31
>  From: Colin Perkins <[EMAIL PROTECTED]>

> On 20 Jul 2005, at 18:26, Bruce Lilly wrote:

> > I recall making no statements about RTP or the way it conveys data
> > save for the fact that that is as irrelevant to defining a media type
> > as are details of TCP or UDP etc.
> 
> You have made, and continue to make, numerous statements about RTP  
> payload formats and their associated media type registrations which  
> are factually incorrect. The most obvious of these is your insistence  
> on treating the RTP transport protocol headers as part of the media  
> data, as you repeatedly do in the message to which I am replying.

I have made statements about the only publicly- and freely-visible format
specification which is referenced by MIME registration forms.  To the
extent that transport protocol overhead has been erroneously included in
what is purported to be a media format specification, that is a problem
with the registration and/or specification.  And I would add that that
causes problems for MIME reviewers and implementers, and said problems
would be alleviated by a separate registry with separate rules, where
RTP-specific registrations can conflate transport bits with format bits
or not without causing problems for MIME reviewers and implementers.

> You are confusing the applicability statement which   
> describes RTP-specific processing with the description of the media  
> type.

I see nothing in 3267 labeled "applicability statement"; I do see
multiple "format" descriptions.
 
> The formats are specified in the following:
> 
>     [1]   3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech  
> transcoding",
>           version 4.0.0 (2001-03), 3rd Generation Partnership Project
>           (3GPP).
> 
>     [2]   3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
>           4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
> 
>     [3]   3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
>           functions", version 5.0.0 (2001-03), 3rd Generation  
> Partnership
>           Project (3GPP).
> 
>     [4]   3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure",
>           version 5.0.0 (2001-03), 3rd Generation Partnership Project
>           (3GPP).

26.090, according to http://www.3gpp.org/ftp/Specs/html-info/26090.htm
is "AMR speech Codec; Transcoding Functions".  Transcoding functions and
media formats are separate types of specifications.  "Frame structure"
specifications *might* be applicable, *if* the media format is identical
to said "frame structure", but I see nothing in the registration form
that says so, and several parts of section 5 imply otherwise; sections
5, 5.1, and 5.2 make no reference to what precisely comprises "speech
frames" or "speech bits" or indeed why two different terms are used.
 
> > That is a very good reason for a separate registry.  There is no  
> > question
> > that the proposed media type did not meet the requirements for  
> > registration
> > in the text top-level MIME registry; it should never have been  
> > proposed to
> > register it there.  With a separate RTP registry, those interested  
> > in RTP
> > can establish whatever rules or lack of rules for things to be  
> > considered
> > as RTP "text".
> 
> You seem to be complaining because we asked the advice of the MIME  
> community on whether the 3GPP timed text format should be registered  
> under text or video, and then took that advice. Quite how this can be  
> construed as a failure of the process, or as a statement that RTP is  
> not appropriate for use with MIME types is beyond me.

One might as well ask whether or not an elephant is eligible for a dog
license.  The question shouldn't even be asked.  And it wasn't a simple
matter of "took that advice", there was argument that even though the
media clearly was incompatible with text, that it should be registered
under text anyway, presumably merely because some RTPers would like it
that way with no regard for the registry's rules.  That the question
was asked is itself an indication of a problem (the rules are quite
clear and are not new; they have been in RFC 2046 which is now more
than eight years old).  That RTPers would like to do things incompatible
with MIME and the MIME registry is a clear indication that both RTP and
MIME communities would best be served by separate registries with
separate rules tailored to the needs of their respective communities.
Both seem quite clear from consideration of the facts... [in the interest
of keeping at least this IETF list discussion civil and professional,
I'll not comment re. your "is beyond me" statement other than to note
that the implications seem clear to me] 

[text/t140]
> > The issue is that there has to be a specification of the format.  The
> > registration form points to RFC 2793.  The format specified in 2793 is
> > what is shown above.  If the authors of 2793 meant that something else
> > was in fact the media format, then that s

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[JFC (Jefsey) Morfin]

At 13:31 22/07/2005, Francois Menard wrote:

IETF-ers,
What is the latest state-of-the-art thinking at the IETF about a 
distributed multiple-root systems for name discovery based on end-to-end 
peer-to-peer PKI-based trust discovery and trust chain management & 
properties/capabilities exchange (I can sign you, you can sign me, I can 
do 4096 bits but you'll only parse 2048, etc.)
Is it permissible to think that this could be an alternative to the DNS at 
some point in time in the future or does the DNS needs to remain as it is?


Dear François,
I suggest first you read http://www.icann.org/icp/icp-3.htm. As you may 
recall the IANA function, name and number space management have been 
contracted by the USG to ICANN and the USG recently published a position on 
the root system, etc. You will find some useful links on the political 
aspects under http://nicso.org/iana.htm. ICANN has an obligation of 
insurring the stability of the DNS. The Part-5 of ICP-3 gives you 
fundamental elements.


I asked several time that the IETF get involved in the requested test-bed 
and I just proposed ccTLD and national communities to build on the 
experience of the dot-root test bed we ran for two years according these 
rules. Some temporary elements could be found in a study we published on a 
paying basis (to cover our costs) in French. This study resulted in 
multiple propositions and efforts.


From this I would not advise to consider multiple-root at all. There is 
only one real root file: the description of the existing TLD forest. But 
you can have multiple visions of that forest. And ways to build your root 
file. This actually results in a root-matrix rather than in a file. The way 
you use and conceive that matrix gives you various possible visions of the 
internet.


Let consider your .travel. If New.net .travel and ICANN .travel are 
orthogonal we have an absurdity. No one can know who is name.travel. But if 
New.net and ICANN .travel are two versions of the same reality there is no 
conflicts. There only can be names which will not resolve or different 
_desired_ resolutions. There is no objection that air-france.travel 
resolves to two different sites if this is the decision of air-france.


So, there is no fuzzy concept of "trust", but a deliberate choice by the 
user to use a root where .travel is upported by ICANN and one where it is 
spported by New.net. Like when you visit Paris you can purchase two 
different Guides.


Where "trust" can be considered it is in the building of the root itself, 
but not exactly as you conceive it. It is absurd to have ICANN building the 
root file with delays which may be of months. It would be far better that 
the root is build from the data published by the TLD Managers: everyone 
could build his root and _mutually_ correct in case of failure or attack. 
The problem is the trust you can have in this data as reflecting the 
decision of the TLD Manager. There is no major problem in having sites 
published by the TLD Manager where he displays his data: the data must be 
the same of 2/3 of them for being acceptable.  However we need a public 
declaration procedure to know what are these sites. This can be achieved by 
a system of Trust as you refer. But a mutual system involving Govs, large 
gTLDs, etc.


ICANN could then lead the system. But its role would not be to accept a 
delegation,. It would only be to make sure it is the origin of the new list 
is the same as the one who published it first.


Such a system exists today we do not notice, it is the name of countries. 
Except about the recent conflict about "Macedonia" it works well.


What you could do to is to use another class than "IN" at least initially.
jfc


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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Stephane Bortzmeyer]

On Fri, Jul 22, 2005 at 10:08:03AM -0400,
 Francois Menard <[EMAIL PROTECTED]> wrote 
 a message of 42 lines which said:

  You, not everybody
  v
> I would for example not trust .travel from new.net if ICANN had assumed 
> control over .travel ... I should be able to pick this from a PKI-based 
> P2P trust chain, would I not?

Since other people would have a different trust chain, this will be a
significant move from the current semantics of the DNS. Today,
"airfrance.travel" is the same for me and for you. With your system,
they may be different.

I do not say that it is good or bad, just that it is a different
system than the one users are accustomed to.



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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Francois Menard]

However, there is more generality to my question ... I need a quick
rundown of the latest thinking (RFCs, ID's, IESG & IAB directives, IRTF
experiments) regarding:

1) distributed multiple roots


I would certainly be interested in any scientific and technical papers
about this issue. This is a very interesting and challenging problem.

But I think that we can safely say that you canNOT have multiple roots
IF you want to keep the present semantics of the DNS. (For instance,
the current semantics is "If I send an email to
[EMAIL PROTECTED], it will arrive in the same malibox,
irrespective of my current email provider". See
http://www.finee.com/travel_tld.htm.)


Wouldn't you be able to resolve to a primary-ness state for a given TLD 
(domain names is just an example of the name resource you could resolve 
to), through a trust relationship.


I would for example not trust .travel from new.net if ICANN had assumed 
control over .travel ... I should be able to pick this from a PKI-based 
P2P trust chain, would I not?



It is not a limit of the current protocols. It is a limit forced upon
us by the requirments: if you want the above semantics for
[EMAIL PROTECTED], you canNOT have multiple roots, because
something (the root) will have to decide who manages
".travel". Otherwise, you will not arrive in Paris for the next IETF
:-)


It would not be the root, it would be the trust chain you build in your 
resolver...



[You can compare with distributed file systems or distributed
databases: you typically have to give in some requirments.]


I have not seem trust chain management in any type of DFS... but I am not 
a specialist in DFS... though I cannot wait to see the day that Ethernet 
interfaces start to ship for SATA drives...


-=Francois=-

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

Re: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Harald Tveit Alvestrand]

You have of course read RFC 2826, "IAB Technical Comment on the Unique DNS 
Root"?


Of course, this is specifically about the DNS, and doesn't answer your 
question as it pertains to non-DNS systems


--On fredag, juli 22, 2005 07:31:48 -0400 Francois Menard 
<[EMAIL PROTECTED]> wrote:




IETF-ers,

What is the latest state-of-the-art thinking at the IETF about a
distributed multiple-root systems for name discovery based on end-to-end
peer-to-peer PKI-based trust discovery and trust chain management &
properties/capabilities exchange (I can sign you, you can sign me, I can
do 4096 bits but you'll only parse 2048, etc.)

Is it permissible to think that this could be an alternative to the DNS
at some point in time in the future or does the DNS needs to remain as it
is?

I am thinking on figthing on the policy front to force a Tier1C
implementation of ENUM with a distributed registry based on the use of
registries at the NPA-NXX- (Co-code) level in Canada while the USA
would remain with a flat file per NPA (Tier 1B)

However, there is more generality to my question ... I need a quick
rundown of the latest thinking (RFCs, ID's, IESG & IAB directives, IRTF
experiments) regarding:

1) distributed multiple roots
2) E2E P2P PKI-based trust discovery and trust chain management
3) capabilities and properties exchange in an E2E PKI environment.

You can tell me to RTFM with reason since I have been out of touch for
the last 5 years, and I will not take it personally, but any investment
of time and energy into providing me some good warnings of "DO NOT GO
THERE" would be very appreciated.

-=Francois=-
--
[EMAIL PROTECTED]
819 692 1383

___
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: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Stephane Bortzmeyer]

On Fri, Jul 22, 2005 at 07:31:48AM -0400,
 Francois Menard <[EMAIL PROTECTED]> wrote 
 a message of 39 lines which said:

> However, there is more generality to my question ... I need a quick 
> rundown of the latest thinking (RFCs, ID's, IESG & IAB directives, IRTF 
> experiments) regarding:
> 
> 1) distributed multiple roots

I would certainly be interested in any scientific and technical papers
about this issue. This is a very interesting and challenging problem.

But I think that we can safely say that you canNOT have multiple roots
IF you want to keep the present semantics of the DNS. (For instance,
the current semantics is "If I send an email to
[EMAIL PROTECTED], it will arrive in the same malibox,
irrespective of my current email provider". See
http://www.finee.com/travel_tld.htm.)

It is not a limit of the current protocols. It is a limit forced upon
us by the requirments: if you want the above semantics for
[EMAIL PROTECTED], you canNOT have multiple roots, because
something (the root) will have to decide who manages
".travel". Otherwise, you will not arrive in Paris for the next IETF
:-)

[You can compare with distributed file systems or distributed
databases: you typically have to give in some requirments.]





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

Re: Re: ietf mailing list Acceptable Use Policy

[John Loughney]

> We were faced with this question some time ago, and the result was the 
> creation of the "IETF Non-WG mailing lists" page, 
> 
> 
> The theory being that if something is listed there, the IETF definitely 
> considers it an IETF list; if it is not listed, it's either not an IETF 
> list, or someone needs to take an action to get it listed (which is simple).
> 
> I think defining rules about what is or is not an IETF list is tricky; it's 
> simpler to list the ones that are.

I think that is a reasonable approach.  Hopefully some of this info is sent in 
the welcome to the list mail someone gets when subscribing to the non-WG lists.

John


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

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Sam Hartman]

BTW, this conversation and a side conversation with John has convinced
me that IESG review should involve a call for comments phase.

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

Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

[Francois Menard]

IETF-ers,

What is the latest state-of-the-art thinking at the IETF about a 
distributed multiple-root systems for name discovery based on end-to-end 
peer-to-peer PKI-based trust discovery and trust chain management 
& properties/capabilities exchange (I can sign you, you can sign me, I can 
do 4096 bits but you'll only parse 2048, etc.)


Is it permissible to think that this could be an alternative to the DNS at 
some point in time in the future or does the DNS needs to remain as it is?


I am thinking on figthing on the policy front to force a Tier1C 
implementation of ENUM with a distributed registry based on 
the use of registries at the NPA-NXX- (Co-code) level in Canada while 
the USA would remain with a flat file per NPA (Tier 1B)


However, there is more generality to my question ... I need a quick 
rundown of the latest thinking (RFCs, ID's, IESG & IAB directives, IRTF 
experiments) regarding:


1) distributed multiple roots
2) E2E P2P PKI-based trust discovery and trust chain management
3) capabilities and properties exchange in an E2E PKI environment.

You can tell me to RTFM with reason since I have been out of touch for the 
last 5 years, and I will not take it personally, but any investment of 
time and energy into providing me some good warnings of "DO NOT GO THERE" 
would be very appreciated.


-=Francois=-
--
[EMAIL PROTECTED]
819 692 1383

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

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Harald Tveit Alvestrand]

--On fredag, juli 22, 2005 00:27:25 +0200 Brian E Carpenter 
<[EMAIL PROTECTED]> wrote:



Sam, I would think that the purpose of a Last Call as part of
IESG review would primarily be not to evaluate success or
failure, but to be sure that the IESG has an opportunity to
hear, from the community, about issues of which the IESG members
might not be aware.


Then I don't think it's a Last Call in the normal sense.
It's what we might whimsically call a Request For Comments.
Seriously, we could call it a Call for Comments.


The IAB has a tradition of issuing "impending publication" notices on their 
architectural guidance documents.


The resulting document is still labelled an IAB document, not an IETF 
consensus document, but I think the process improves the output (You'd have 
to ask the IAB what they think about the resulting feedback, however).


If something works - copy it :-)


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

Re: e2e [Re: Port numbers andIPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Masataka Ohta]

Brian E Carpenter wrote:

> I have to agree that e2e cannot create network level QoS that isn't 
> available -
> if the best path available can't offer the desired QoS, no end system 
> magic can
> achieve that QoS. But it can at least make the best use of the QoS 
> available,
> e.g. by reducing a streaming data rate to avoid random loss.

The problem is that the meaning of "end" varies. For example,
with mobility, a home agent is an end and with multicast, some
entity which manages a group is an end (which is why dense
mode multicast with no such entity does not scale).

As for QoS, it can be said that all the intermediate routers are
ends.

In a sense, systems on a path between a source and a destination
may be ends, as long as the path is determined dynamically and
the systems hold dynamic state only, because the systems have
proper knowledge on the ongoing communication.

In a sense, "end" means a system with proper knowledge and control
on the ongoing communication.

For example, as for QoS, PDP, which definitely is not "end" with
limited knowledge and control, destroyed E2E property.

Masataka Ohta



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