Re: Subscriber List Damage

[Simon Josefsson]

Glen <[EMAIL PROTECTED]> writes:

> I'm happy to discuss this further; however, I do not want to pollute
> the various lists with this.  I'm cc'ing the lists in this case so
> everyone understands we are responding to emails, but I'm going to
> take any further threads off-list to keep the lists focused on their
> primary purposes.

How about an IETF "operations" mailing list?  There is the tools mailing
list, but I don't think this kind of operational discussions belong
there.  People interested in the operations of various IETF servers
could join that mailing list.  The list might even be an helpful
resource for incidents like this.

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

Re: Subscriber List Damage

[Glen]

Unfortunately I really don't have anything but assumptions about what 
happened at this point.


An increase in TMDA activity caused the system to run out of resources. 
 We saw an extremely high load average and a sudden decrease in kernel 
buffer memory.  Processes started to fail to fork.  Our engineers 
connected in, and rebooted the server.


Upon reboot, we quickly discovered that the IETF list, which we 
moderate, was no longer letting us in with the normal list password.  A 
quick check showed that the database file config.pck was now only about 
50% of its original size, and that many subscribers had been removed - 
and others added.  Passwords and other settings had been "reverted" to 
pre-cutover values.  A comparison with our recent backup of the file 
showed massive differences - not just removals, but additions.  We 
hypothesize that mailman fell back to some type of cached copy of the 
database from 2005, which was also in the directory, and recreated the 
data from that.


Unfortunately, we have no way to verify what happened, and certainly 
don't want to try to cause it again.


I believe our solution is going to be to remove TMDA completely, which, 
I believe will eliminate the side-effects we've been seeing such as this.


I'm happy to discuss this further; however, I do not want to pollute the 
various lists with this.  I'm cc'ing the lists in this case so everyone 
understands we are responding to emails, but I'm going to take any 
further threads off-list to keep the lists focused on their primary 
purposes.


Glen

Eric Rescorla wrote:

At Mon, 30 Jun 2008 15:48:10 -0700,
Michael Thomas wrote:

1) Have you brought this up with the mailman folks? I've interacted with
them and they seem like a responsive set of folks. I'm sure that 
this sort

of thing would horrify them.


I agree that this is horrifying.

More importantly, doesn't this mean that this is a problem we actually
need a solution for pronto? As I understand Glen's message, he's
saying that this is a bug in mailman triggered by some problem in
TMDA. I realize that TMDA is being replaced, but presumably Henrik's
code isn't perfect, so don't we have to worry about it triggering the
same behavior?

Glen, I'm sure there are some people on this list who understand
mailman well. I realize you may not have complete info, but if you can
provide us some more information--e.g., what file(s) got stomped and
which code you think stomped it--about what you think happened, maybe
they can help track it down?

-Ekr



2) 3 years since the last backup? Oi.

   Mike

Glen wrote:

All -

I was asked by the IAOC to post a message to the IETF and SIP lists, 
to ensure that people were aware that the subscriber lists for the 
IETF and SIP lists were damaged as a result of an anomaly in TMDA and 
Mailman that occurred Thursday night.


Basically, TMDA misbehaved, and, in the process, caused Mailman to 
encounter a transient failure in the reading of its databases for 
these two lists.  As a result, rather than simply holding the mail and 
retrying it, Mailman decided to discard the current list databases and 
re-create them from 3-year-old data, for both the IETF and the SIP lists.


*sigh*

No email was lost to the system or the archives; however, some people 
may have missed some messages, or may still not be resubscribed to the 
list.


Of course we restored the files from backups; however, we want to make 
sure that everyone gets the mail they missed, and that everyone is 
subscribed to these lists who wishes to be subscribed.


So...

If you're reading this message in your email box, you're subscribed to 
the list identified in the subject line, and all should be okay.


If you're reading this message in the archives, wondering why you're 
not getting list mail, please take a moment to resubscribe yourself to 
the list, which should resolve your problem.


And regardless, if you feel you missed any mail, we do have the 
archives available for your reference.


IETF List Subscription Link:  https://www.ietf.org/mailman/listinfo/ietf
IETF List Archive Link:  http://www.ietf.org/mail-archive/web/ietf/

SIP List Subscription Link:  https://www.ietf.org/mailman/listinfo/sip
SIP List Archive Link:  http://www.ietf.org/mail-archive/web/sip/

We are in the home stretch of getting TMDA removed and replaced on the 
servers, and I apologize for any inconvenience caused by this issue. 
Because server problems apparently happen only in the dead of night, 
you can be sure that we feel any and all pain anyone may be experiencing.


If you need any assistance, please contact the IETF Secretariat, using 
the links at:  http://www.ietf.org/secretariat/


Thank you,
Glen Barney
IT Director
AMS (IETF Secretariat)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinf

Re: Subscriber List Damage

[Eric Rescorla]

At Mon, 30 Jun 2008 15:48:10 -0700,
Michael Thomas wrote:
> 
> 1) Have you brought this up with the mailman folks? I've interacted with
> them and they seem like a responsive set of folks. I'm sure that 
> this sort
> of thing would horrify them.

I agree that this is horrifying.

More importantly, doesn't this mean that this is a problem we actually
need a solution for pronto? As I understand Glen's message, he's
saying that this is a bug in mailman triggered by some problem in
TMDA. I realize that TMDA is being replaced, but presumably Henrik's
code isn't perfect, so don't we have to worry about it triggering the
same behavior?

Glen, I'm sure there are some people on this list who understand
mailman well. I realize you may not have complete info, but if you can
provide us some more information--e.g., what file(s) got stomped and
which code you think stomped it--about what you think happened, maybe
they can help track it down?

-Ekr


> 2) 3 years since the last backup? Oi.
> 
>Mike
> 
> Glen wrote:
> > All -
> >
> > I was asked by the IAOC to post a message to the IETF and SIP lists, 
> > to ensure that people were aware that the subscriber lists for the 
> > IETF and SIP lists were damaged as a result of an anomaly in TMDA and 
> > Mailman that occurred Thursday night.
> >
> > Basically, TMDA misbehaved, and, in the process, caused Mailman to 
> > encounter a transient failure in the reading of its databases for 
> > these two lists.  As a result, rather than simply holding the mail and 
> > retrying it, Mailman decided to discard the current list databases and 
> > re-create them from 3-year-old data, for both the IETF and the SIP lists.
> >
> > *sigh*
> >
> > No email was lost to the system or the archives; however, some people 
> > may have missed some messages, or may still not be resubscribed to the 
> > list.
> >
> > Of course we restored the files from backups; however, we want to make 
> > sure that everyone gets the mail they missed, and that everyone is 
> > subscribed to these lists who wishes to be subscribed.
> >
> > So...
> >
> > If you're reading this message in your email box, you're subscribed to 
> > the list identified in the subject line, and all should be okay.
> >
> > If you're reading this message in the archives, wondering why you're 
> > not getting list mail, please take a moment to resubscribe yourself to 
> > the list, which should resolve your problem.
> >
> > And regardless, if you feel you missed any mail, we do have the 
> > archives available for your reference.
> >
> > IETF List Subscription Link:  https://www.ietf.org/mailman/listinfo/ietf
> > IETF List Archive Link:  http://www.ietf.org/mail-archive/web/ietf/
> >
> > SIP List Subscription Link:  https://www.ietf.org/mailman/listinfo/sip
> > SIP List Archive Link:  http://www.ietf.org/mail-archive/web/sip/
> >
> > We are in the home stretch of getting TMDA removed and replaced on the 
> > servers, and I apologize for any inconvenience caused by this issue. 
> > Because server problems apparently happen only in the dead of night, 
> > you can be sure that we feel any and all pain anyone may be experiencing.
> >
> > If you need any assistance, please contact the IETF Secretariat, using 
> > the links at:  http://www.ietf.org/secretariat/
> >
> > Thank you,
> > Glen Barney
> > IT Director
> > AMS (IETF Secretariat)
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Subscriber List Damage

[Glen]

Michael Thomas wrote:

1) Have you brought this up with the mailman folks? I've interacted with
   them and they seem like a responsive set of folks. I'm sure that this 
sort

   of thing would horrify them.


I haven't yet, but will try.  They'll probably want more information 
than I can give them.



2) 3 years since the last backup? Oi.


No - not three years since the last backup.  I have MUCH more recent 
backups than that, of course!


Three years is the age of the file that I suspect mailman used to pull 
its old configuration from.  An old copy of the database for those two 
lists that was just sitting around, not being used.


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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Mark Andrews]

> On Mon, Jun 30, 2008 at 05:49:18AM -0700,
>  David Conrad <[EMAIL PROTECTED]> wrote 
>  a message of 11 lines which said:
> 
> > Speaking technically, how would you distinguish the top-level domain
> > "127.0.0.1" from the IP address 127.0.0.1?
> 
> A word while passing here: is there a document (RFC, Posix standard,
> whatever) which says which is the right result in such a case?
> 
> There are protocol-specific rules. RFC 3986, section 3.2.2, clearly
> says that the IP address wins and so your example would be regarded
> as the localhost IP address, wether the TLD ".1" is delegated or no.
> 
> But I do not find generic rules.
> 
> RFC 3493 which specifies getaddrinfo is not very clear. Section 6.1
> apparently does not address your issue.
> 
> So, I would say there is a normalization failure here: since 127.0.0.1
> can be a domain name and an IP address, we really should have
> precedence rules for such case (instead of asking ICANN to solve them
> by forbidding all-numeric TLD).

I think you will find that getaddrinfo() implementations
catch IP address rather than look them up.  The question is
more what they catch rather than when they catch.

For IPv6 it is pretty straight forward.  There is a recommend
a followed syntax.

IPv4 on the other hand has lots of history involved.  OS's
with lots of history tend to support very liberal syntaxes.
OS's with not so much history tend to be limited to dotted
decimal quad.

ICANN is in a position to look at what the various OS's
accept and rejects TLD's application that will potentially
conflict with the existing practice of any current OS.  This
will prevent users that switch OS's and use something other
than dotted decimal quad getting a match in the DNS when
the new OS is not as permissive as the old OS.

> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Subscriber List Damage

[Michael Thomas]

1) Have you brought this up with the mailman folks? I've interacted with
   them and they seem like a responsive set of folks. I'm sure that 
this sort

   of thing would horrify them.
2) 3 years since the last backup? Oi.

  Mike

Glen wrote:

All -

I was asked by the IAOC to post a message to the IETF and SIP lists, 
to ensure that people were aware that the subscriber lists for the 
IETF and SIP lists were damaged as a result of an anomaly in TMDA and 
Mailman that occurred Thursday night.


Basically, TMDA misbehaved, and, in the process, caused Mailman to 
encounter a transient failure in the reading of its databases for 
these two lists.  As a result, rather than simply holding the mail and 
retrying it, Mailman decided to discard the current list databases and 
re-create them from 3-year-old data, for both the IETF and the SIP lists.


*sigh*

No email was lost to the system or the archives; however, some people 
may have missed some messages, or may still not be resubscribed to the 
list.


Of course we restored the files from backups; however, we want to make 
sure that everyone gets the mail they missed, and that everyone is 
subscribed to these lists who wishes to be subscribed.


So...

If you're reading this message in your email box, you're subscribed to 
the list identified in the subject line, and all should be okay.


If you're reading this message in the archives, wondering why you're 
not getting list mail, please take a moment to resubscribe yourself to 
the list, which should resolve your problem.


And regardless, if you feel you missed any mail, we do have the 
archives available for your reference.


IETF List Subscription Link:  https://www.ietf.org/mailman/listinfo/ietf
IETF List Archive Link:  http://www.ietf.org/mail-archive/web/ietf/

SIP List Subscription Link:  https://www.ietf.org/mailman/listinfo/sip
SIP List Archive Link:  http://www.ietf.org/mail-archive/web/sip/

We are in the home stretch of getting TMDA removed and replaced on the 
servers, and I apologize for any inconvenience caused by this issue. 
Because server problems apparently happen only in the dead of night, 
you can be sure that we feel any and all pain anyone may be experiencing.


If you need any assistance, please contact the IETF Secretariat, using 
the links at:  http://www.ietf.org/secretariat/


Thank you,
Glen Barney
IT Director
AMS (IETF Secretariat)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

Gen-ART LC review of draft-ietf-smime-cms-rsa-kem-05

[Ben Campbell]

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

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


Document: draft-ietf-smime-cms-rsa-kem-05
Reviewer: Ben Campbell
Review Date:  2008-06-30
IETF LC End Date: 2008-07-04
IESG Telechat date: (if known)

Summary: This draft is almost ready for publication as a proposed  
standard. I have one substantive comment which should be considered  
prior to publication, and a few nits.


Comments:

--Substantive:

This draft normatively references RFC 3280, which was obsoleted by RFC  
5280 after this draft was published. The authors should consider  
whether it would be appropriate to update the reference prior to  
publication. I have no opinion on how invasive such an update might  
be, so I am categorizing this as substantive, although it could really  
just be a nit.


--Nits:

The draft appears to be expired,  Also, the short title still claims  
to be version 04.


Section 2, paragraph 2:

 I'm not sure what to make of the SHOULD consider statement along  
with the last sentence. Do you intend any statement of preference for  
one or the other, or effectively saying we should consider both?


Section 2.1, paragraph 5:

The last sentence is hard to follow due to the chained "whiles". Can  
it be rephrased?


Section 2.2, first paragraph:

Odd line spacing. This occurs a few times throughout the document.

Section 2.3, right before definition of RSAPublicKey, "... type  
RSAPublicKey type:"


Redundant "type"

Section 3, paragraph 1:

It might be helpful to add a short paragraph explaining the  
significance of this algorithm mapping to a random oracle in lay terms  
(or at least in terms where a person generally familiar with IETF  
protocols but not cryptology jargon would understand.)


Paragraph 10 (starting with "Implementations SHOULD NOT reveal...")

Are there any documents that could be referenced here to elaborate on  
this guidance to implementors? Right now, this draft says enough to  
let implementors know they need to worry about side channels, but does  
not provide much concrete advice on how to avoid them. To be clear, I  
don't think this document _should_ provide such guidance itself; if no  
such documents exist in a form that could be referenced, then so be it.


Appendix A:

The appendix uses the term "byte" in multiple locations where "octet"  
might be less ambiguous. (Assuming that "byte" was not preferred on  
purpose.)

















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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Philip Guenther]

On Mon, 30 Jun 2008, Stephane Bortzmeyer wrote:

On Mon, Jun 30, 2008 at 05:49:18AM -0700,
David Conrad <[EMAIL PROTECTED]> wrote
a message of 11 lines which said:


Speaking technically, how would you distinguish the top-level domain
"127.0.0.1" from the IP address 127.0.0.1?


A word while passing here: is there a document (RFC, Posix standard,
whatever) which says which is the right result in such a case?


POSIX (IEEE Std 1003.1, 2004 Edition, aka the Single UNIX Specification, 
Version 3) specifies both inet_pton() and inet_addr().  The latter is 
required to accept the 'traditional' forms for IPv4 addresses with fewer 
than four components or using hex or octal numbers.  Contrawise, the 
former is forbidden from accepting such forms.


So the answer from that direction is "it depends".


Philip Guenther
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Update of RFC 2606 based on the recent ICANN changes ?

[David Conrad]

On Jun 30, 2008, at 12:01 PM, Stephane Bortzmeyer wrote:

Speaking technically, how would you distinguish the top-level domain
"127.0.0.1" from the IP address 127.0.0.1?


A word while passing here: is there a document (RFC, Posix standard,
whatever) which says which is the right result in such a case?


Not that I'm aware of (and that's sort of the point), however there is  
a lot of code out there that are variations on checking to see if a  
string is comprised of all digits and '.' and if so, declares the  
string to be an IP address.  If an all-numeric TLD were to be created,  
I would expect lots of unexpected behavior.


Sort of like the concerns about unexpected behavior that resulted in  
rejecting UTF-8 labels and coming up with punycode.



So, I would say there is a normalization failure here: since 127.0.0.1
can be a domain name and an IP address, we really should have
precedence rules for such case (instead of asking ICANN to solve them
by forbidding all-numeric TLD).


I'm not asking that ICANN solve this problem, rather that the IETF  
solve it so that ICANN can point to the IETF solution.  Having been in  
some of the discussion internally within ICANN on this topic, I figure  
something like this would be really nice...


Regards,
-drc

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Stephane Bortzmeyer]

On Mon, Jun 30, 2008 at 05:49:18AM -0700,
 David Conrad <[EMAIL PROTECTED]> wrote 
 a message of 11 lines which said:

> Speaking technically, how would you distinguish the top-level domain
> "127.0.0.1" from the IP address 127.0.0.1?

A word while passing here: is there a document (RFC, Posix standard,
whatever) which says which is the right result in such a case?

There are protocol-specific rules. RFC 3986, section 3.2.2, clearly
says that the IP address wins and so your example would be regarded
as the localhost IP address, wether the TLD ".1" is delegated or no.

But I do not find generic rules.

RFC 3493 which specifies getaddrinfo is not very clear. Section 6.1
apparently does not address your issue.

So, I would say there is a normalization failure here: since 127.0.0.1
can be a domain name and an IP address, we really should have
precedence rules for such case (instead of asking ICANN to solve them
by forbidding all-numeric TLD).

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Stephane Bortzmeyer]

On Mon, Jun 30, 2008 at 08:43:28AM -0400,
 John C Klensin <[EMAIL PROTECTED]> wrote 
 a message of 83 lines which said:

> there will be no practical difference between an IDN gTLD and an IDN
> ccTLD other than the ability of the operator to shield itself from
> any potential ICANN enforcement action --even of agreements that
> were signed to get the domain--

Before bashing the ccTLD, wait the final text of the "IDN fast track"
process document. In its current version
,
it does not mandate agreements between ICANN and the ccTLD, far from
it.

"The GAC also feels that it would be inappropriate for new IDN ccTLDs
to be obliged to enter into contractual agreements with ICANN,"

That's just GAC's opinion but it is apparently the only place where
these agreements are mentioned.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: SHOULD vs MUST case sensitivity

[Dave Crocker]

Ralph Droms wrote:

Would a reasonable BCP for future docs looks something like:

  terms defined in RFC 2119 are to be capitalized for clarity; 
alternatives for RFC 2119 terms, such as "ought" and "can" are to be 
used in

  non-normative text to avoid confusion


+1

Thanks.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Frank Ellermann]

John C Klensin wrote:

> rules like this are ultimately useless unless ICANN agrees to 
> them, presumably via the gNSO, one at a time, and via a PDP 
> process.

As long as PDP translates into "individual Last Call comments"
for a future draft-ietf-idnabis-952bis that's fine.  

Nothing rush like 

> it seems to argue that we should be conservation about what
> names we reserve and thereby promote.

Sure, there also rules about not creating confusingly similar
TLDs, proposed TLDs exmaple or examlpe won't pass that check.

> Perhaps we should ask ICANN to reserve all single-letter TLDs
> (in any script) for IETF use.

s/ICANN/IANA/, and that is an odd idea.  We don't need 2**20
example TLDs.  But a few would be nice, for examples in EAI
and IDNAbis drafts, or similar.

 Frank

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Frank Ellermann]

David Conrad wrote:

> TLDs starting with a number but containing non-numerics would be  
> disallowed (I'm reminded of the fun long ago with 3com.com)?

Yes, killing the  "0x" 1*HEXDIG  oddity.  I wasn't thrilled when
my browser supported the  "feature".

 Frank

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

Re: SHOULD vs MUST case sensitivity

[Ralph Droms]

Would a reasonable BCP for future docs looks something like:

  terms defined in RFC 2119 are to be capitalized for clarity;  
alternatives for RFC 2119 terms, such as "ought" and "can" are to be  
used in

  non-normative text to avoid confusion

- Ralph

On Jun 30, 2008, at Jun 30, 2008,10:08 AM, Spencer Dawkins wrote:

Without reference to other points that have been made in this  
thread, it's also worth noting that Gen-ART reviewers have been  
challenging 2119-ish statements in drafts under review for several  
years, assuming that capitalization is significant, and discouraging  
upper-casing for emphasis.


It would be lovely to have the current practice written down  
clearly, so authors and editors aren't surprised when this happens  
(and we never have to revisit the topic).


Thanks,

Spencer


However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt.  The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect.  It is also based at least in part on the the
arguments put forward in this thread.  And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.

Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not
technically required to indicate the intended usage - it is a
very good idea to do this.  Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.

--
Eric Gray
Principal Engineer
Ericsson


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Crocker
Sent: Sunday, June 29, 2008 10:32 PM
To: Randy Presuhn
Cc: IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity



Randy Presuhn wrote:
>> English is not case sensitive.
>
> Not so.  Case has long been used for emphasis in environments
> lacking other typographical means, such as bolding, underlining,
> or italicization.


Emphasis is not semantics.

Normative intent is semantic.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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



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


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

Re: SHOULD vs MUST case sensitivity

[Spencer Dawkins]

Without reference to other points that have been made in this thread, it's 
also worth noting that Gen-ART reviewers have been challenging 2119-ish 
statements in drafts under review for several years, assuming that 
capitalization is significant, and discouraging upper-casing for emphasis.


It would be lovely to have the current practice written down clearly, so 
authors and editors aren't surprised when this happens (and we never have to 
revisit the topic).


Thanks,

Spencer


However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt.  The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect.  It is also based at least in part on the the
arguments put forward in this thread.  And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.

Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not
technically required to indicate the intended usage - it is a
very good idea to do this.  Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.

--
Eric Gray
Principal Engineer
Ericsson


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Crocker
Sent: Sunday, June 29, 2008 10:32 PM
To: Randy Presuhn
Cc: IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity



Randy Presuhn wrote:
>> English is not case sensitive.
>
> Not so.  Case has long been used for emphasis in environments
> lacking other typographical means, such as bolding, underlining,
> or italicization.


Emphasis is not semantics.

Normative intent is semantic.

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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




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

RE: SHOULD vs MUST case sensitivity

[Eric Gray]

Dave,

Let's try to close this argument in a constructive way.

We could argue the extent to which "Best Current Practice"
RFCs actually specify anything - rather than simply encouraging
a commonly accepted practice.  Based on that argument - and lots
of usage evidence (represented - among other things - by text 
you've quoted) - RFC 2119 appear to state that the terms in 
question are often capitalized.  And that supports a further
argument that RFC 2119 is suggesting this should be the case -
given that it is a common practice.

We could also make the semantic argument that you've made
- i.e. - that capitalization is not essential to the semantics
that RFC 2119 encourages RFC authors to use.  It is certainly 
going to be the case that some RFCs will be published with the
intent for these terms to be normative, and where not every 
instance is in ALL-CAPS - and this should not mean necessarily
that these words are not meant to be taken as normative.

However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt.  The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect.  It is also based at least in part on the the
arguments put forward in this thread.  And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.

Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not 
technically required to indicate the intended usage - it is a 
very good idea to do this.  Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.

--
Eric Gray
Principal Engineer
Ericsson  

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Dave Crocker
> Sent: Sunday, June 29, 2008 10:32 PM
> To: Randy Presuhn
> Cc: IETF Discussion
> Subject: Re: SHOULD vs MUST case sensitivity
> 
> 
> 
> Randy Presuhn wrote:
> >> English is not case sensitive.
> > 
> > Not so.  Case has long been used for emphasis in environments
> > lacking other typographical means, such as bolding, underlining,
> > or italicization.
> 
> 
> Emphasis is not semantics.
> 
> Normative intent is semantic.
> 
> d/
> -- 
> 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Update of RFC 2606 based on the recent ICANN changes ?

[David Conrad]

John,

On Jun 30, 2008, at 5:43 AM, John C Klensin wrote:
The other two things that seem to be getting lost in this discussion  
is that one can write all of the RFCs one like, but rules like this  
are ultimately useless unless ICANN agrees to them


ICANN has already deferred to the IETF on technical matters (see  
IDNs).  I'm unclear why ICANN would ignore IETF technical input on  
this matter.


I don't know if the gNSO would like that or not, but it seems to  
argue that we should be conservation about what names we reserve and  
thereby promote.


Yep.  The only additional label (to those in 2606) that seems to have  
a technical justification for being disallowed would appear to be  
".local" due to the zeroconf(-like) mechanisms that use it.


Perhaps we should ask ICANN to reserve all single-letter TLDs (in  
any script) for IETF use.


I don't necessarily agree or disagree, but what would be the technical  
justification?


Regards,
-drc

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[David Conrad]

On Jun 29, 2008, at 8:31 PM, Frank Ellermann wrote:

| Executive summary:  Obsoletes RFC 952, updates RFC 1123,
| defines  toplabel = letter 0*61( ldh ) letdig


So, TLDs starting with a number but containing non-numerics would be  
disallowed (I'm reminded of the fun long ago with 3com.com)?


Regards,
-drc

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[David Conrad]

are numeric string representations now, after 30 years



going to be outlawed? if so, on what basis?


?

I'm suggesting that there are technical reasons why strings comprised  
of all numbers and those that start with 0x and contain hex digits  
should not be TLD labels.


In theory, the limitation against all-numeric/hex TLD labels should  
not need to be made.  However, in theory, a label can support any  
octet value between 0 and 255 yet the IETF has gone to great lengths  
to greatly limit the values within "hostname" labels...


Regards,
-drc

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[David Conrad]

Stephane,

On Jun 29, 2008, at 11:41 PM, Stephane Bortzmeyer wrote:

a TLD is a domain like any other.


In theory, yes.  In reality, no.  Speaking technically, how would you  
distinguish the top-level domain "127.0.0.1" from the IP address  
127.0.0.1?


Regards,
-drc

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

Re: Update of RFC 2606 based on the recent ICANN changes ?

[John C Klensin]

--On Sunday, June 29, 2008 7:46 PM -0700 Bill Manning 
<[EMAIL PROTECTED]> wrote:




I'm suggesting it would be helpful if there were an RFC
directing IANA   to establish a registry that contains both
labels and rules (e.g, no   all-numeric strings, no strings
that start with 0x and contain   hexadecimal values, the
string 'xn--', the 2606 strings, etc.) that   specify what
cannot be placed into the root zone.  As part of future
IANA actions, any time a protocol defines a new TLD (e.g.,
.local) an   entry should be placed into that registry.

Would there be the downside to this?


several come to mind...

heres one.  wrt numeric strings, you have examples of the
ambiguity   in implementations on -how- to process non-base 10
numbers.  but   it is clear that hex encoding is -not- tossed
out.  how 'bout octal?  or base 36?  are numeric string
representations now, after 30 years going to be outlawed? if
so, on what basis?

creating a useful RFC that creates a registry and maintains
it in a timely  fashion -in this century- seems a bedtime
fable.


The other two things that seem to be getting lost in this 
discussion is that one can write all of the RFCs one like, but 
rules like this are ultimately useless unless ICANN agrees to 
them, presumably via the gNSO, one at a time, and via a PDP 
process.  The odds of the very-commercially-oriented gNSO 
agreeing to the IETF's being able to pull a name out of the 
potential namespace by simple IETF consensus (or less) are, IMO, 
around zilch.  Worse, as we move toward IDN TLDs, the odds are 
high that there will be no practical difference between an IDN 
gTLD and an IDN ccTLD other than the ability of the operator to 
shield itself from any potential ICANN enforcement action --even 
of agreements that were signed to get the domain-- by claiming 
national sovereignty and the rule that, in general, private 
bodies can't sue governments without the permission of those 
governments.


The complementary problem is that, in the present DNS 
environment in which typing errors are monetized, an effect of a 
reservation of "example.com" is registration of, e.g., 
"examlpe.com" and "exmaple.com" as placeholders, perhaps in case 
they draw enough traffic that someone would like to buy them 
(the web page for the first of these contains an explicit offer 
to sell it).


To at least some extent, our reserving a name and (if the use in 
plain-text examples, rather than, e.g., MIB examples actually 
drives non-trivial traffic toward those names) publicizing it 
makes spelling variations of that name more valuable.  I don't 
know if the gNSO would like that or not, but it seems to argue 
that we should be conservation about what names we reserve and 
thereby promote.


That has an interesting corollary: to the extent to which 
domains, especially web sites, consider unexpected access to be 
a potential profit source, rather than an annoyance, using 
someone else's domain name in an example may be "welcome free 
advertising", rather than a "rude intrusion".  One can argue 
against use of those names on either basis, but let's stop 
pretending that we have complete knowledge of what is going on 
here and of the consequences of our actions.


Perhaps we should ask ICANN to reserve all single-letter TLDs 
(in any script) for IETF use.  That would make the examples very 
clear, would avoid driving traffic to alternate sites (since we 
would "own" all of them) and would constitue a relatively closed 
list :-)


   john

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