> On Wed, Mar 03, 2004 at 04:18:42PM -0500, Joe Abley wrote:
> >
> > If you find an answer, telling this list would be good.
> >
> > In the past the answer has been "you don't", often coupled with
> > enthusiastic statements about the mbone being in full production, and
> > tunnels no longer being
On the economic front, there have been offers, at least from me, to PAY for
remote attendance. Let's face it, I'd have been happy to pay $500 to have
access to all WG sessions and plenaries via Real Player or other Unicast
mechanism in Seoul. There's just no way my company can afford the travel
exp
> On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote:
> > So a "secure ports only" policy has very little to do with security and
> > very much to do with organizational power relationships, and making
> > your computing environment dysfunctional.
> Somebody check my math on this please, but it seems t
> On the other hand, STARTTLS *requires* a clear channel that the client
> MUST *already* be using. So whereas the attack on SSL *might* succeed in
> putting the client in touch with an unencrypted service, TLS is
> *guaranteed* to be using such a service already anyway. The only question
> is whet
> > A definitive authoritative specification for all variations of the
> > mbox database format is explicitly not the objective, for several
> > reasons.
> that's fine. I fully support registering application/mbox as a media
> type.
> > For
> > one thing, such a definition is outside the IETF's
Keith, very nicely put. I am in complete agreement with everything you
say here.
Ned
On Aug 17, 2004, at 8:38 PM, Dave Crocker wrote:
> If someone can summarize where
> this thread is going and/or should go, I'd appreciate it.
my recommendation to the author -
-
> > 9. Acknowledgements
> >
> >Variations on the idea of using a DNS record to check the
> > legitimacy
> >of an email address have occurred multiple times. The earliest
> > known
> >work is [Vixie]; others include [RMX], [SPF] and [CallerID].
> >
> >The current
On Aug 30, 2004, at 7:05 PM, John Day wrote:
> The best solution is to remove all authorship from all Internet
> standards, then there will be no problems. This isn't suppose to be
> an ego trip. If people really think the documents are important, they
> don't need their names on them. If they n
At 2:30 PM +0200 9/28/04, Eliot Lear wrote:
> Just to be clear, I trust the leadership to decide better than I
> can. I don't know about the rest of you, but I have a day job that
> has absolutely nothing whatsoever to do with IETF governance. I'd
> like to have the time to go over all this fun s
> In many situations around the world in developing countries, it is
> totally impossible to send a 10MB e-mail because the link will be at
> least break once in the time it takes to send 10MB. As e-mail does not
> resume...
FWIW, RFC 1845 specifies such a mechanism for SMTP. There have been
few i
> > I am somewhat sympathetic to the idea of having some
> > total limit (except for the late date for the proposed change).
> Earlier feedback would have been had if there had been
> some announcement of the proposed considerable changes
> on the ietf-822 mailing list, or via an IETF WG
> charter
> I have been following the extensive discussions of this subject
> on the IETF and Language-Tags lists (somewhat over 100 relevant
> messages by my rough count, although with the vast major of them
> from around five participants). I note that much of it has not
> been explicitly copied to the IE
This whole question of what 'matches' is subtle. Consider the case
when I have a document that has variant content by language (e.g.
different sound tracks), and the user indicates a set of preferred
languages. If the content has "de-CH" and "fr-CH" (swiss german and
french), and a default "en" (
Small typo: In my previous response I referred to RFC 1766 when I meant
RFC 3066. Too many documents open at once, sorry.
Ned
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
> [EMAIL PROTECTED] scripsit:
> > I know of two other wrinkles in the RFC 1766 world:
> Are you aware that RFC 1766 has been obsolete for four years now?
Of course I am.
> > (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact
> >sufficiently different languages that a
> > > Finding country codes is straightforward: any non-initial subtag of
> > > two letters (not appearing to the right of "x-" or "-x-") is a country
> > > code. This is true in RFC 1766, RFC 3066, and the current draft.
> > On the contrary, in RFC 3066 the rule is "any 2 letter value that
> > a
> > Date: 2005-01-05 10:33
> > From: [EMAIL PROTECTED]
> > > Section 2.5 (2.4.1 in the draft) states the matching rule in a succinct
> > > fashion. ÂEverything in 2.4.2 is a non-normative elaboration of this.
> >
> > ??? Which in no way refutes my assertion that no matching rule algorithm
> > wa
> > For the triple of
> > language/country/script to match usefully in the general case by
> > RFC 3066 parsers (which are unaware of script in general), the first
> > and second subtags would have to remain language code and country
> > code respectively.
> If you consider realistic scenarios, th
> [EMAIL PROTECTED] scripsit:
> > Now, it may be the case that all _registered_ tags have avoided the use of
> > non-country code two letter codes in the third and later position. But this
> > is
> > 100% irrelevant.
> If you say so.
> > The point is that conformant code implementing RFC 3066 i
> > Rather, the rule is simply that a country code, if present,
> > always appears as a two letter second subtag. The new draft changes this
> rule,
> > so applications that pay attention to coutnry codes in language tags have
> to
> > change and the new algorithm for finding the country code is tr
> > From: [EMAIL PROTECTED] [mailto:ietf-languages-
> > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> > My reading of that text is that it goes out of its way to try and
> avoid
> > direct
> > discussion of a matching algorithm, talking instead about "rules" and
> > "constructs". I no longer
> And I will assume that it was that perceived insult that caused you to be
> dismissive,
I was dismissive because your correction, while accurate, was irrelevant
to the current discussion of the change to country code semantics.
> with your statement below about "Fine, whatever." I assume that
>
> In a nutshell, Ned was elaborating on a comment from Dave Singer that,
> once we have parsed a pair of tags and identified all the pieces, it's
> not a trivial matter to decide in every case how the two tags compare,
> and that there are factors that would exist if the draft were approved
> that
> Hi,
> Our anti-virus system tags all IETF draft announcements as being potentially
> dangerous. I suspect because of the unusual options to fetch the data that
> are encoded in the MIME header.
> We would certainly like to see that feature removed from IETF announcements,
> as it seems archaic
--On torsdag, februar 10, 2005 10:49:50 -0500 Bruce Lilly
<[EMAIL PROTECTED]> wrote:
> 1. I have in mind a keyboard on a certain device which has
>support for protocols which use domain names (HTTP, SMTP/
>Internet Message Format, VPIM). It has a keyboard which
>is at best inconvenie
> Bruce, fwiw, this general approach was discussed when this
> protocol was first being designed.
Not only was it discussed, the draft actually specified this scheme at one
point.
It was overwhelmingly rejected by the participants at the time and removed.
> I can't remember all of the
> reasons
> On Fri March 4 2005 22:43, [EMAIL PROTECTED] wrote:
> > Not only was it discussed, the draft actually specified this scheme at one
> > point.
> > The problem in a nutshell was that it required client modifications.
> Ned, if I understand your remarks correctly, you are claiming that
> the sche
>> if we could get rid of wireless and powerpoint, we'd be much better
>> off.
>
> Personal opinion: disagree. Wireless is immensely useful to grab a
> document, check something on another SDO's web site, and - yes - for
> instant messaging (e.g. "we need you in here right now"). And some
> people
> On Tue March 15 2005 16:25, The IESG wrote:
> > The IESG has received a request from an individual submitter to consider the
> > following document:
> >
> > - 'Media Type Specifications and Registration Procedures '
> > as a BCP
> >
> > The IESG plans to make a decision in the next few weeks,
> On Tue March 29 2005 14:03, [EMAIL PROTECTED] wrote:
> [I wrote]
> > > Section 4.2.1 might benefit from a clarification of "text" as
> > > communication in a natural language intended primarily for human
> > > consumption (perhaps something like the description in BCP 18).
> >
> > Perhaps, but t
> On Tue April 5 2005 15:30, Alex Rousskov wrote:
> > On Wed, 2005/03/02 (MST), <[EMAIL PROTECTED]> wrote:
> >
> > > I've suggested (via Reply-To) discussion on the IETF list.
> >
> > Bruce,
> >
> > Thanks a lot for reviewing and commenting on the draft!
> >
> > I am preparing a revision to add
> On 4/7/2005 10:36, Brian E Carpenter allegedly wrote:
> > Regardless of the interesting side-discussion about 'voting',
> > what the toy shows after about a day is:
> >
> > prefer nroff: 8
> > prefer xml: 37
> > neither: 9
> I wonder how many of those have actually written a draft using bo
On 15 Mar 2005, at 21:25, The IESG wrote:
> The IESG has received a request from an individual submitter to
> consider the following document:
>
> - 'Media Type Specifications and Registration Procedures '
> as a BCP
>
> The IESG plans to make a decision in the next few weeks, and solicits
> fi
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of [EMAIL PROTECTED]
> > Sent: Tuesday, April 12, 2005 12:57 PM
> > To: Colin Perkins
> > Cc: iesg@ietf.org; ietf@ietf.org
> > Subject: Re: Last Call: 'Media Type Specifications and
> > Registration P
> Date:Tue, 12 Apr 2005 21:20:28 +0100
> From:Colin Perkins <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> | RFC 3555 allows media types to be defined for transport only via RTP.
> | The majority of these registrations are under the audio and video
> | t
Bruce Lilly wrote:
(Interesting thoughts read and deleted)
...
> One problem is that the IESG routinely sabotages development along
That is, I think, an inappropriate choice of word.
> the Standards Track by disbanding WGs as soon as a PS is produced,
> leaving nobody to do the work necessary fo
> Brian, and others,
> I do have experience of WGs that care about DS.
So do I. But this has not been the norm in my experience.
Ned
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
> This is a very good example of the approach that many folks have taken, in
> thinking about these problems. It is really pretty amazing, given the nature
> and history of this community. It is not immodest to assert that we are a
> community of relatively self-actualized participants, with a co
In addition to choosing the right way to look at the distribution of
total action times, I strongly recommend breaking down the transactions
into component parts and looking at the details. The exchange I had
with Sam Hartman was a good example. On 5/23. Sam wrote:
> I'd think two months woul
On Fri, 3 Jun 2005, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'Email Submission Between Independent Networks '
>as a BCP
This seems a good document, but could probably still use a bit of
polishing.
I think yo
> > Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> > Date: 2005-06-08 10:50
> > From: Ned Freed <[EMAIL PROTECTED]>
> > > .. RFC2119, when used, must be a normative reference. Likewise,
> > > you'll need to ad
On Wed, 8 Jun 2005, Ned Freed wrote:
>> A practical issue I have with this doc is that the recommendations are
>> relatively few, and most of them are rather generic or vague.
>> Haven't we learned more on email BCPs by now?
>
> What we have learned and what we are a
> From where I sat, the problem was trying to ensure that a WG thought
> about an issue. Neither mandatory material nor checkoff boxes
> accomplish that, but I think the former is often more useful because
> material in an I-D is visible to the entire WG.
I disagree completely and think you have
> Ned Freed <[EMAIL PROTECTED]> writes:
> > Like it or not, careful reviews and review checklists, while quited
> > flawed in their own right, are the best tool we have. When I was on
> > the IESG I had my own private review checklist; it was the only
> > thin
On Fri, 10 Jun 2005, Ned Freed wrote:
>> What exactly is it that you
>> think should be done (in addition to careful reviews) that would help
>> reduce the odds that the careful review find issues with the IANA
>> instructions (or lack thereof)?
>
> Simple:
> It is the requirement that Internet Drafts always contain IANA
> considerations sections that has to go.
Ned, you have not produced any argument for this position, and since
the absence of such a section does not imply the absence of IANA
considerations, your logic continues to escape me.
R
Dave,
>Here's my own take:
>
>It is empty bureaucracy. It is form, without content. It is additional
>effort, with no benefit.
>
>It is reasonable and necessary to require that documents contain
>important considerations. This is not accomplished by having pro forma
>sections lacking content
> I don't see that sort of probing on our MXs, except on rare occasions, and
> we haven't seen it recently.
FWIW, my logs on mrochek.com (my home domain) show around 35,000 relay attempts
during the past 6 months. This number is almost certainly much too low, in that
I have various other blocks in
> Keith,
> > it's possible to have open relays that don't contribute to spam. but
> > those relays need to employ some other means, e.g. rate limiting, to
> Rate limiting is a relatively recent technique. Though very useful it has...
> ummm, limited applicability.
Actually, in my neck of the
> Ned> Unfortunately so is the presence of an empty IANA
> Ned> considerations section - you cannot tell the difference
> Ned> between such a section that was arrived as as a result of
> Ned> careful review of the draft and one that was simply created
> Ned> as a form of boilerp
> > And this requirement is quite new. It would be unprecedented if it hadn't
> > triggered some level of initial review in these very early days. But wait
> > a couple of years for the new to wear off and people being people will
> > start to handle it as more boilerplate.
> For anyone who w
> > Date: 2005-06-23 12:45
> > From: Ned Freed <[EMAIL PROTECTED]>
> > Which in turn works because there are always security considerations - the
> > closest thing to valid empty security considerations section we have is one
> > that says "this enti
> To state that somewhat differently, since we cannot effectively
> prohibit the deployment of an extension or option of which the
> IETF disapproves, the best things we can do for the Internet are
> make it as easy as possible to identify the use of the extension
> so it can be effectively quarant
Perhaps things have settled down sufficiently for me to express an
opinion...
I am not an IANA weenie. But I think registries should register
things.
We have a decent amount of running code (for example,
http://www1.ietf.org/mail-archive/web/ietf/current/msg35953.html) that
says our attempts
> Can anyone suggest where I could find the requirement for IANA
> Considerations?
There is no requirement that such sections appear in published RFCs. This
debate has never been about what's required in RFCs, but rather what's required
in drafts submitted to the IESG.
> I found it on the website
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote:
> RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does
> discuss them, and we will need to form consensus about whether the RFC
> Editor is required to retain them, as we discuss RFC2434bis. Which we
> need to do fairly soon.
I
On Jul 6, 2005, at 11:20 AM, Ned Freed wrote:
> This is exactly what I predicted would happen - the IANA
> considerations section has now become part of the boilerplate in at
> least one I-D template. (Actually make that two - I put in in my own
> equivalent template some time bac
> > This opens the door to the author forgetting to check and the various
> > reviewers assuming the prsence of the sections means a check was done.
> The goal of putting it in the template is to encourage it be addressed,
> rather than forgotten altogether.
I am well aware of what the goal is, a
> *> harmful, and that the best way to insure coverage of IANA issues is to
> have an
> *> explicit check for such things as part of our review process.
> *>
> As I expect you know, the IANA checks all documents at Last Call time,
> and the RFC Editor checks them before publication, for mis
> > Date: 2005-07-06 16:16
> > From: Joe Touch <[EMAIL PROTECTED]>
> > Ned Freed wrote:
> > > This is exactly what I predicted would happen - the IANA considerations
> > > section
> > > has now become part of the boilerplate in at least on
> That said, I think we should be paying careful attention to
> Bruce's implied suggestion about how template
> boilerplate-generators should be constructed. In terms of the
> checking process Ned asks for (and which I still believe is the
> right solution) there is a world of difference between
> > > I suppose. That said, if IANA considerations was *not* built into the
> > > boilerplate, it would have a high likelihood of being omitted.
> >
> > Which would then be noted on checklist review, causing a fairly careful
> > check
> > to be made to see if there really aren't any considerations
> On Thu July 7 2005 15:32, Ned Freed wrote:
> > I have never suggested that the requirment for an IANA considerations
> > section
> > in documents that contain IANA considerations be dropped.
> The specific requirement is for the presence of a section in an I-D
> p
> > I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
> > the port number space. I know it's off-topic here, but anyone know why
> > they didn't? It surely must have been considered.
> It would not make much sense, between 2 hosts you can already have
> 65536*65536 possible conn
On 15-jul-2005, at 3:25, Ned Freed wrote:
>> It would not make much sense, between 2 hosts you can already have
>> 65536*65536 possible connections*, which should be more than
>> enough(tm) ;) I wonder if there are any hosts actually using more
>> than
>> 6553
Ned Freed wrote:
Mind you, I'm not saying that TCP needs to be redesigned ASAP to allow
> for a
> larger number of source ports. IMO the pain would probably outweigh the
> gain.
> But that doesn't mean nobody is hitting the 65536 limit imposed by
> source port
>
On 15-jul-2005, at 18:11, Ned Freed wrote:
> The specific case I've seen is with IMAP4. IMAP4 has the
> characteristic that you often have a huge number of incoming
> connections, only
> a few of which are active at any given time.
I know what you mean, I've seen my Ma
On 15-jul-2005, at 19:14, Ned Freed wrote:
>> If they are, they're probably using some kind of proxy or NAT setup,
>> for instance, having SSL sessions decrypted and then forwarded to the
>> actual server port, making all the sessions seem to come from the
>> sa
> > From: Ned Freed <[EMAIL PROTECTED]>
> Let me make sure I understand you here:
> > IMAP4 has the characteristic that you often have a huge number of
> > incoming connections, only a few of which are active at any given time.
> > Designing serv
> > From: Ned Freed <[EMAIL PROTECTED]>
> >> You're saying that there are servers which have close to (or more)
> >> than 65K connections to a *single client IP address* (i.e. it may be a
> >> NAT, with a number of hosts behind it)?
&
> On Fri, Jul 15, 2005 at 09:58:29AM -0700, Ned Freed wrote:
> > >Out of curiosity, doesn't SCTP have a bigger port space (or its
> > >moral equivalent)? If so, would that be a better option?
> >
> > I have in fact on several occasions proposed using SCT
--On torsdag, juli 14, 2005 21:33:05 -0400 Sandy Wills <[EMAIL PROTECTED]>
wrote:
> Directed towards the IESG:
> Recording meetings, and publishing those recordings, may be a hassle,
> but it answers all questions about the integrity of the decision-making
> process. There may still be
Brian E Carpenter wrote:
> Michael, you've had some quite concrete responses which I hope
> have clarified things, but I really want to say that making
> Internet protocols secure isn't a hoop jumping exercise; it's
> more like a survival requirement, and has been for ten years
> at least.
Wher
Your view of requirements for IETF process do not match mine and your
assessment of the current situation with the DKIM effort does not match mine.
They match mine pretty well, however.
In fact I do not know what specific behaviors, and by whom, you are
complaining about.
Actually, I think M
I thought that what Russ asked for was not a threat analysis for
DKIM, but a threat analysis for Internet e-mail, the system that DKIM
proposes to protect. The idea is that only if we start with a
characterization of how and why we believe adversaries attack e-mail,
can we evaluate whether any pro
I think that's right. However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
live with its limitations and quirks every day. We need to understand
the indirect consequences of our choices: not "can it be coded and will
it interoperate?" but
Ned Freed wrote:
>> Brian E Carpenter wrote:
>> > Michael, you've had some quite concrete responses which I hope
>> > have clarified things, but I really want to say that making
>> > Internet protocols secure isn't a hoop jumping exercise; it's
>
> All the more reason for those in charge to be quite specific about what
> it is they're after, which still hasn't happened. All we get is more fixation
> on the words Mike happened to use in one message rather than responding to his
> issue with the lack of clarity in what's being asked for.
> On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote:
> > are you of the opinion that the IESG should try to police which experiments
> > get run on the Internet by refusing to publish RFCs documenting
> > possibly-conflicting experments?
> It depends on the form of the conflict.
> I beli
> > From: Bruce Lilly <[EMAIL PROTECTED]>
> > > This
> > > is all what this proposition is about. This proposition is to give
> > > _one_shot_ in a _standardised_ way the language, the script and the
> > > country.
> >
> > This was discussed during Last Call of the previous non-IETF
> (individual
On 10-aug-2005, at 20:47, The IESG wrote:
> The IESG has received a request from the DNS Extensions WG to
> consider the
> following document:
> - 'Linklocal Multicast Name Resolution (LLMNR) '
> as a Proposed Standard
> The IESG plans to make a decision in the next few weeks, and sol
> On 8/30/2005 2:18 PM, Stuart Cheshire wrote:
> > Well, in case 1 (mDNS), no, because it won't return a useful result, so
> > why keep doing it?
> >
> > In case 3 (conventional DNS), no, because it won't return a useful
> > result, so why keep doing it?
> >
> > In case 2 (LLMNR) the answer is ye
At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:
>That is about 1/3 of the total. It doesn't surprise me at all that
>so many bogus queries arrive - everybody who mistypes a TLD or
>misconfigures a default domain generates bogus queries, and this isn't
>going to change. The question is whether .
> On 8/31/2005 12:36 PM, Ned Freed wrote:
> > Section 2 states:
> that's unfortunate
> LLMNR clients need to make a distinction between the different kinds of
> networks and then process the names accordingly.
Agreed. And there are various ways to accomplish this.
>
On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:
>> "Juergen" == Juergen Schoenwaelder <[EMAIL PROTECTED]>
>> writes:
>
> Juergen> Sam,
>
> Juergen> this is not about blocking port 22 as far as I understand
> Juergen> things. I think
Ned Freed wrote:
> If I were to object to Eliot's proposal (I don't - in fact I strongly
> support
> it), it would be on the grounds that the IETF should be taking a long
> hard look
> at the issues surrounding call home in general, not just in the special
> case o
> Bernard Aboba <[EMAIL PROTECTED]> writes:
> > b. Confusion between security issues and namespace separation. In
> > peer-to-peer name resolution protocols, it is possible for a responder
> > to demonstrate ownership of a name, via mechanisms such as DNSSEC. It
> > is also possible for a respon
> Friends,
> I believe that Keith's first paragraph below is widely accepted by the
> IETF. However, after re-reading RFC 3234, RFC 3303, and others I did not
> find any text within any RFC to explain our consensus opinion concerning
> correct middlebox behavior to be used to guide those outside o
> In message <[EMAIL PROTECTED]>, Brian E Carpenter writes:
> >Eduardo Mendez wrote:
> >
> >> What IETF discuss may hurt thir people, peace, culture.
> > > But I am sure IETF Member do not realize this?
> > > If they were told they would understand.
> >
> >What people do with technology may have g
On 29 okt 2005, at 15.40, Harald Tveit Alvestrand wrote:
>>
>> Amorality among scientists, engineers, and technologists has
>> gotten the
>> world into a lot of trouble. I prefer to think about the
>> consequences
>> of what I do.
>>
>
> I think we all do, and I think it's one of the reasons
> Dave,
> > It is pretty much never a good idea to have the mechanics of a process
> > contain artificial constraints, as a means of implementing higher-level
> > policies.
> >
> > If a working group is worried about documents getting read, they will
> > impose their own deadlines or they will con
> The IETF mandates the use of UTF-8 for text [RFC2277] as part of
> internationalisation. When writing an RFC, this raises a number of issues.
> A) Character set. UTF-8 implicitly specifies the use of Unicode/IS10646 which
> contains 97,000 - and rising - characters. Some (proposed) standards
> From: "Ned Freed" <[EMAIL PROTECTED]>
> To: "TomPetch" <[EMAIL PROTECTED]>
> Cc: "ietf"
> Sent: Friday, December 23, 2005 7:13 PM
> Subject: Re: Troubles with UTF-8
>
> > > (Unicode
> > > lacks a no-op, a meaningles
> Ned Freed wrote:
> >> (Unicode lacks a no-op, a meaningless octet, one that could
> >> be added or removed without causing any change to the
> >> meaning of the text).
> > NBSP is used for this purpose.
> My proposal u+FFFE was nonsense, I wanted u+
> Lets go ahead and ask then -
> Does anyone else think that IETF should allow documents which
> format/structure is not publicly known as one of the ways to
> distribute IETF specifications?
For the record, my answer is "absolutely not".
> And why do all the other SDOs get along with non-
> > > They seem to have it in place of the word "Neustar" CNRI
> > > used to have their name there, and no logo. CNRI's had its
> > > name there at least since 1996, so it's kind of traditional
> > > to name the operator.
> > It's traditional, and I think fair. I'll ask the IAD to see if
> >
> >Here is the revised proposed charter text:
> Thanks for pulling this together.
> If I had unlimited time to waste, I might niggle about a word or two,
> but it's fine as is, and I look forward to moving ahead and getting
> some work done.
Complete ageement here. This is plenty good enough to
> > Second, your assumption that other SDOs have been able to blissfully make
> > use
> > of private formats like MS Word without incident is simply untrue. One
> > obvious
> > counterexample I know of is the CCITT/ITU, which has in the past used MS
> > Word
> > as a distribution format for many
> In message <[EMAIL PROTECTED]>, Scott W Brim writes:
> >On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
> >> Are you looking for normative figures? If so, can you point to an
> >> example where you think they are necessary? (I'd like to avoid a
> >> discussion of packet diagrams for the mo
> > I disagree that the use of diagrams is a religious issue. Diagrams
> > are a very simple way to put specification and context together
> > in a compact notation such that it is easy to move from key
> > point to key point in a non-linear way. They provide visual
> > hyperlinking.
> Stewart,
>
1 - 100 of 274 matches
Mail list logo
