Subject: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Sep 2007 19:09:14 +0100

This message is trying to summarize recent discussions on 
draft-hartman-webauth-phishing-05.txt.

Several people voiced their support for the document (on IETF mailing 
list and in various other off-list discussions). Ekr doesn't think that 
the document should be published in the current form and he has some 
good technical points that need to be addressed. At least one more 
revision is needed to addressed recent comments from Ekr and SecDir review.

It is quite clear that some people got confused about intended status of 
this document and whether it represents IETF consensus. Sam has 
clarified what was his intention, but another consensus call is needed 
to make sure people agree with Sam.

Subsequent discussions and consensus calls on the document would happen 
on <[email-masked]>.

Alexey,
in my capacity of shepherd for draft-hartman-webauth-phishing

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Sep 2007 13:53:36 -0700

> in my capacity of shepherd for draft-hartman-webauth-phishing

I object to this procedure.

This document has already had an IETF Last Call, where it failed to
achieve consensus. At this point, it doesn't need additional last
calls to "make sure that people agree with Sam", but rather to go back
to the authors to try to build support in the community. Not liking
the result of the previous Last Call is not a sufficient basis for
issuing another one.

At some point in the future, it may be appropriate to issue another
consensus call, but since this is not a WG mailing list--indeed, the
IESG has twice declined to charter a WG in this area--nor are you the
chair, it doesn't seem to me that you have standing to do that. When
that time comes, I would expect the IESG to designate an appropriate
time and place.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Sep 2007 16:52:06 -0700 (PDT)

> that time comes, I would expect the IESG to designate an appropriate

I agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
does not support the process that has been recommended here.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 09 Sep 2007 19:30:01 +0100

Eric Rescorla wrote:

>achieve consensus.
Ekr, I have to disagree with you.
One objection about the document and one objection about the intended 
status doesn't constitute "failed consensus", considering there are at 
least 8 other people who are in favor of publishing the document. I can 
publish the list of reviewers, if you insist.

>At this point, it doesn't need additional last
>to the authors to try to build support in the community.
>
I was probably not clear enough in my previous message:
1). The document needs more work.
2). The document needs more reviews. Discussions of future revisions 
should happen on [email-masked]
3). The document was effectively reset to pre-IETF LC state.

>Not liking the result of the previous Last Call is not a sufficient basis for
>issuing another one.
>  
>
This statement taken in isolation is certainly correct. However if the 
original LC didn't ask the right question, don't you think this makes 
answers meaningless?

>that time comes, I would expect the IESG to designate an appropriate
I have support of the shepherding AD.
Do you think this is insufficient?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Sep 2007 23:37:45 +0200

On 8-sep-2007, at 20:09, Alexey Melnikov wrote:

> This message is trying to summarize recent discussions on draft- 
> hartman-webauth-phishing-05.txt.

> Several people voiced their support for the document (on IETF  
> mailing list and in various other off-list discussions). Ekr  
> doesn't think that the document should be published in the current  
> form and he has some good technical points that need to be  
> addressed. At least one more revision is needed to addressed recent  
> comments from Ekr and SecDir review.

Here's an outsider review.

What's an Ekr, btw?

I really dislike the use of "fishing" with creative spelling in a  
document prepared for an international standards organization. The  
world certainly doesn't need more words that sound the same and  
differ in meaning only by the way they're written, and I'm not sure  
how prevalent this terminology is outside the US and/or the English  
speaking world. Please come up with something more descriptive.

During the reading of this document, it occurred to me that HTTP  
digest authentication (RFC 2617) rather than the widely used practice  
of having security credentials be typed into an HTTP form would  
achieve 90% of the requirements all by itself. (More or less the same  
thing for S/MIME in mail.) The main part that's missing there is  
protection against a man in the middle. Obviously TLS goes through  
great pains to avoid men in the middle, but the document has no  
trouble throwing that out of the window:

    The attacker can also spoof trust markers
    such as the security lock, URL bar and other parts of the browser  
UI.

And:

    Users do not typically understand
    certificates and cannot make informed decisions about whether the
    subject name in a certificate corresponds to the entity they are
    attempting to communicate with.  As a consequence of this  
assumption,
    users will likely be fooled by strings either in website names or
    certificates that look visually similar but that are composed of
    different code points.

Although I agree that a system that can work even under these  
assumptions would be great, I think it's harmful to adopt them in  
this way, because it sends a number of very bad messages:

- it's ok for browser vendors to play fast and loose with security  
related UI elements such as the lock icon and the URL bar (i.e., have  
them controlled by the remote server)

- it's ok for domain vendors to sell domains that use IDN trickery

- it's ok for certificate vendors to sell certificates that seem to  
be tied to some known entity but are in reality tied to a different  
entity

All of these are unacceptable and we as users of these services,  
community members, engineers and IETF members should do what we can  
to make sure that they don't happen.

Last but not least, I'm guessing that "ben Laurie" is actually "Ben  
Laurie".

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 9 Sep 2007 18:51:05 -0400

On Sep 9, 2007, at 5:37 PM, Iljitsch van Beijnum wrote:

>> addressed. At least one more revision is needed to addressed  
>> recent comments from Ekr and SecDir review.
>

I tend to rely on Dictionaries to sort these things out - from  
Dictionary.com

-----
Webster's New Millennium™ Dictionary of English - Cite This Source

Main Entry:
phishing

Part of Speech:
n
Definition:
the practice of luring unsuspecting Internet users to a fake Web site  
by using authentic-looking email with the real organization's logo,  
in an attempt to steal passwords, financial or personal information,  
or introduce a virus attack; the creation of a Web site replica for  
fooling unsuspecting Internet users into submitting personal or  
financial information or passwords
Example:
1996; as in 'fish' for users
Etymology:
phish, v; phisher, n

Webster's New Millennium™ Dictionary of English, Preview Edition (v  
0.9.7)
Copyright © 2003-2007 Lexico Publishing Group, LLC
-----

So, my personal opinion is that it would be OK with an definition.

Regards
Marshall

> digest authentication (RFC 2617) rather than the widely used  
> practice of having security credentials be typed into an HTTP form  
> would achieve 90% of the requirements all by itself. (More or less  
> the same thing for S/MIME in mail.) The main part that's missing  
> there is protection against a man in the middle. Obviously TLS goes  
> through great pains to avoid men in the middle, but the document  
> has no trouble throwing that out of the window:
>
>    such as the security lock, URL bar and other parts of the  
> browser UI.
>
> And:
>
> related UI elements such as the lock icon and the URL bar (i.e.,  
> have them controlled by the remote server)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2007 01:21:00 +0200

> I tend to rely on Dictionaries to sort these things out - from  

Dictionaries are useless, when in doubt they just add definitions.  
For instance, try figuring out how many bytes there are in a megabyte  
from a few dictionaries.

---

From: Bill Manning <[email-masked]>
Date: Sun, 9 Sep 2007 16:48:39 -0700

> For instance, try figuring out how many bytes there are in a megabyte  

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, 
`it means just what I choose it to mean -- neither more nor less.'

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 9 Sep 2007 18:47:58 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 

> During the reading of this document, it occurred to me that 
> HTTP digest authentication (RFC 2617) rather than the widely 
> used practice of having security credentials be typed into an 
> HTTP form would achieve 90% of the requirements all by 
> itself. 

Well maybe if people had listened to me then :-)

But at this point fifteen years later Digest is not the way to go. First Digest was designed under the express constraint of avoiding patent encumberances. RSA and D-H were both off the table at the time.

If I was to redo Digest today or expand its scope I would do it differently. The main reason I would not is that SAML and WS-* both provide an excellent solution. I very much like and support the Cardspace idea of building into the O/S platform. I very much like the OpenID concept of making the barrier to entry very low. I would like to arrive at a happy combination of the existing proposals not see more proposals put on the table at this point.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 10 Sep 2007 16:52:35 -0400

> I object to this procedure.
shep>
> that time comes, I would expect the IESG to designate an appropriate

I think you're overreacting, possibly due to a misinterpretation of what 
Alexey said and/or of the current state of the document.

My reading of the IESG evaluation record suggests that there are indeed 
some issues that the community feels need to be addressed before the 
document can move forward.  Its current state is "IESG Evaluation::Revised 
ID Needed", which, along with the evaluation record, suggests that the 
responsible AD has asked the author and shepherd to get these issues 
resolved and submit a new document.  I don't know what will happen once 
this is done, but unless the IESG feels we already have _rough_ consensus 
to publish the document _and_ there are no major changes, I would expect to 
see a new last call on the revised document.  Of course, that last call may 
see renewed objections from the same individuals, or from others; that does 
not necessarily mean the last call "failed" -- remember, we operate on 
_rough_ consensus.

Now, given that the responsible AD has asked for a new document, it seems 
to me that Alexey, as the shepherd of an individual submission, has quite a 
bit of latitude in how to get there and what it will take before he is 
willing to take the document back to the IESG.  Given that this document is 
a group effort, it's entirely reasonable for Alexey to want to know that 
people contributing to the work agree with any changes Sam makes, and to 
issue consensus cals in an appropriate forum to do this.  No one is 
laboring under the impression that such a call would serve to "override" 
the "failed" IETF LC.  Instead, when Alexey in his role as shepherd 
believes the document is ready to go back to the IESG, he will inform Lisa 
of that fact, and the IESG will decide what to do next.

-- Jeff
-- Jeff

---

From: Paul Leach <[email-masked]>
Date: Mon, 10 Sep 2007 16:29:24 -0700

I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration.

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 12:19:22 +0100

> `it means just what I choose it to mean -- neither more nor less.'

There has been a discussion recently on LTRU as to whether a Terms and
Definitions section should be introduced within RFCs - much like those
within ISO Standards.

Best regards

Debbie Garside

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: 10 September 2007 00:49
> To: Iljitsch van Beijnum
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Alexey Melnikov;
> [email-masked]
> Subject: Re: Next step on web phishing
> draft(draft-hartman-webauth-phishing-05.txt)
>

---

From: Paul Leach <[email-masked]>
Date: Mon, 10 Sep 2007 16:29:24 -0700

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 12:19:22 +0100

Best regards

Debbie Garside

---

From: "tom.petch" <[email-masked]>
Date: Mon, 10 Sep 2007 16:45:36 +0200

----- Original Message -----
From: "der Mouse" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2007 4:14 PM
Subject: Re: [saag] Next step on web phishing
draft(draft-hartman-webauth-phishing-05.txt)

> > document prepared for an international standards organization.
>
> Perhaps unfortunately, that is *the* word for the behaviour in
> question, at least in English.  It was not invented for the draft, and
> "com[ing] up with something [else]" would be *less* descriptive and
> would render the document cryptic to the people who's been working
> against phishing for years.  Perhaps it's a bad word to use in other
> languages, but that should be addressed by the translator(s) in
> question, not by mangling the original.
>

Stick the word in quotes which conveys the message that we know that this is not
a good piece of terminology, but that we are pragmatic enough to recognise that
using it will convey the right meaning to most people.

But on the other strand under this Subject:, I am with those who think that the
IETF has demonstrated an absence of consensus and that the proposed way forward
to try and achieve it by other means in plain wrong.

Tom Petch

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 12:04:01 -0700 (PDT)

> Definitions section should be introduced within RFCs - much like those

And my response to this suggestion is the same as it was for the "IANA
considerations" or "Internationalization considerations" section suggestions:
By all means have a "terms and definitions" section or whatever in the document
if there's a need for one, but don't make having one mandatory in all
documents.

We already have more than enough useless (from a technical content
perspective) boilerplate in our documents. We don't need any more, and
when such sections are always present but usually say "no such and such
are present" they aren't helping.

The last time this came up in the context of IANA considerations it was
asserted that having such sections act as a useful check to make sure there are
no needed definitions or considerations. The problem is people don't work this
way. If the section is mandatory they'll add it when the document is first
created. Sometimes they'll remember to keep it up to date and sometimes they
won't. But when someone reviews the document they'll see that section
and assume its presence means whatever has been checked. So the mandatory
section approach can actually result in more errors and omissions, not less.

It took me only a few minutes the last time we had one of these discussions
to find a documentt (in the RFE Editor's queue, as I recall) where
this had happened: A "there are no IANA considerations" section had been
added early on but when the document acquired IANA considerations it
wasn't updated. And nobody who reviewed the document caught it.

				Ned

P.S. I've read a lot of ISO and CCITT specifications and I have found
their terms and definitions material to be fairly hit or miss in terms of
utility.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 11 Sep 2007 15:39:22 -0400

> I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into considerati…

Would someone send a pointer to Eric Rescorla's critique of the
draft? I couldn't find it, although I found comments by various 
other folks on the IETF draft tracker.

--Shumon.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 16:11:03 -0400

> perspective) boilerplate in our documents. 
+1

Actually I don't have so much of a problem with having such sections in
drafts at review time, but I hate to see them clutter up published
RFCs.    There are a lot of times when these sections aren't applicable,
and having them in the final document just interferes with readability. 

I also think that a Terms and Definitions section might encourage
document authors to make up new terms when they're not necessary, which
would also interfere with readability.  (geeks love to create new language.)

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 16:55:57 -0400

Ned Freed wrote:
>> RFCs.
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Date: Tue, 11 Sep 2007 16:55:57 -0400
From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
OpenPGP: id=E1473978
Cc: [email-masked], [email-masked],
	'Iljitsch van Beijnum' <[email-masked]>, [email-masked],
	[email-masked], [email-masked], Debbie Garside <[email-masked]>,
	[email-masked]
Subject: Re: Next step on web
	phishing	draft(draft-hartman-webauth-phishing-05.txt)

Ned Freed wrote:
>> RFCs.
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith

there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 17:05:11 -0400

Oh, it's very useful to have consistent terminology. And if a document
needs to use new terms, they should definitely be defined before use.  I
just don't want to encourage people to make up new terms (or more
likely, whole new paradigms with their own lexicons) when existing ones
will do.  I'm reminded of recent work in NEA, but they're not the only ones.
> I agree.  Which is why a Terms and Definitions section is darn useful as is
> an overall Term Bank.  However, I will not labour the point as I have long
> ago found that trying to sell Terminology standardization to industry is
> practically impossible - unless you rename it as Knowledge Management.
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 14:33:28 -0700 (PDT)

> For the record, things like IANA considerations sections should be
> required of I-Ds, even if to say that there aren't any.  A single such
> section gathering several such sub-sections should do ("Misc
> Considerations.  This draft has no IANA considerations.  This draft has
> no ...").

I have already explained why I think this is a Very Bad Idea.

> And some such sections might be removed by the RFC Editor, or
> not (e.g., remove IANA considerations sections that say there are no
> IANA considerations).

This I agree with - it is up to the RFC Editor to determine what's appropriate
to have in the final document.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Sep 2007 15:40:31 -0600

> I have already explained why I think this is a Very Bad Idea.

Agreed. In my experience, the IANA does not want the I-D to contain a
section entitled "IANA Considerations" if there are no actions required
of the IANA.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 14:43:14 -0700 (PDT)

> ultimately, interoperability.

I think this is absolutely true of drafts - the target audience is composed of
people with substantial expertise in networking and who are tasked with finding
any potential problems that cound arise, including obscure ones.

In the case of RFCs things aren't so simple. The RFC Editor has to balance a
wide variety of competing and sometimes conflicting goals, including but not
limited to keeping the publication series as a whole consistent, making sure
intellectual property concerns are addressed, seeing that neophytes aren't
misled and insuring the material is laid out sensibly. A substantial amount of
both expertise and perspective is required - something individual authors
cannot be relied on to have.

The IETF has a whole has an unfortunate tendency to want to second guess the
RFC Editor in a lot of this. IMO this tendency is something we need to resist.

> That applies to the copyright

My undestanding is that it happens all the time. (I cannot speak from personal
experience because of late all of the documents I've dealt with have had
non-null IANA considerations.)

> I-Ds - the fewer hoops they have to jump through, the better.)

This is the heart of the issue. I think having IANA considerations on
a separate checklist is an excellent idea, with two possible
answers: (1) The document has IANA considerations and they are
described in an IANA considerations section and (2) The document has
been checked and found not to have any IANA considerations.

The key difference here is _when_ this information is provided. A submission
form isn't going to  be filled out in advance so there's a good chance it will
relect the current state of the document. A null IANA considerations section
that's in the document will likely as not be there from the start, and if it
doesn't get updated it becomes an active source of confusion.

> less readable end product.

Agreed, although I really don't know what can be done about it that we're not
already doing.

> I'd like to see more use of "NOTEs IN DRAFT"
> belongs in the final publication.

Having a single section of this sort is fine and something I and lots of others
do fairly routinely, if for no other reason than to keep track of changes to
the draft. But beyond that I think there are dragons lurking -  having such
notes scattered throughout the document is bound to cause confusion about
what's supposed to be in the published RFC.

I will also say that while having crisp technical content is of paramount
importance, RFCs are used for lots of purposes and our aversion to providing
more than a bare minimum of contextual information is in many cases quite
counterproductive. A lot of our documents would be improved tremendously by
having nonnormative "how we got to this point" appendices in the published
version.

> I'm concerned about readability

Well, in the abstract sense of course I'm more concerned about the published
document. But IMO a significant fraction of the responsibility for that has to
be - and in practice is - borne by the RFC Editor. It is therefore appropriate
for authors to focus on making their drafts maximmally suitable for the part of
the process the IETF is responsible for - getting the technical content right.

				Ned

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 21:56:49 +0100

Ned wrote:

> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.

Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled
egg and I, in interpreting your request, presented you with scrambled egg...
You may be somewhat disappointed at breakfast! ;-)

Best regards

Debbie Garside

> From: Ned Freed [mailto:[email-masked]]
> Sent: 11 September 2007 21:27
> To: Keith Moore
> Cc: Ned Freed; Debbie Garside; [email-masked];
> [email-masked]; 'Iljitsch van Beijnum';
> [email-masked]; [email-masked]; [email-masked];
> phishingdraft(draft-hartman-webauth-phishing-05.txt)
>
>
> > >> There has been a discussion recently on LTRU as to
> whether a Terms
> > >> and Definitions section should be introduced within RFCs - much
> > >> like those within ISO Standards.
> > >>
> > >
> > > And my response to this suggestion is the same as it was for the
> > > "IANA considerations" or "Internationalization
> considerations" section suggestions:
> > > By all means have a "terms and definitions" section or
> whatever in
> > > the document if there's a need for one, but don't make having one
> > > mandatory in all documents.
> > >
> > Actually I don't have so much of a problem with having such
> sections
> > in drafts at review time, but I hate to see them clutter up
> published
> > RFCs.
>
> My position is the exact opposite. Full and complete review
> of drafts it of paramount importance and anything thqt
> interferes with that is unacceptable.
> And as I have pointed out, we have "running code"
> demonstrating that these things are at best distracting and
> at worst actively interfere with proper review.
>
> What's appropriate to appear in the final RFC is up to the
> RFC Editor. That's what the word "editor" implies. If the RFC
> Editor deems it appropriate to remove null sections that's
> fine, if they feel they should be retained that's fine too.
> Someone reading an RFC to learn how to implement something
> has a definite goal in mind and isn't going to be (or at
> least shouldn't be) distracted by boilerplate in the same way
> a reviewer looking for issues - a far more nebulous
> proposition - can be.
>
> > There are a lot of times when these sections aren't applicable, and
> > having them in the final document just interferes with readability.
>
> It depends on what sort of reading you're doing.
>
> > document authors to make up new terms when they're not necessary,
> > which would also interfere with readability.  (geeks love to create
> > new language.)
>
> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.
>
> RFC 2119 is a case in point. While I have some small issues
> with how RFC 2119 defines its terms, I've come to realize
> that having consistent meanings for these terms is far more important.
>
> 				Ned
>
>
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)

> There are a lot of times when these sections aren't applicable,

> would also interfere with readability.  (geeks love to create new language.)

Very good point. Having lots of slightly varying definitions of various terms
could be hugely harmful.

RFC 2119 is a case in point. While I have some small issues with how RFC 2119
defines its terms, I've come to realize that having consistent meanings for
these terms is far more important.

				Ned

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 21:56:49 +0100

Best regards

Debbie Garside

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)

Ned

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Sep 2007 16:10:21 -0500

This thread has morphed into something else entirely.  Please change the
subject and move it to an appropriate list (I've set Reply-To:
[email-masked]; please respect it).

no ...").  And some such sections might be removed by the RFC Editor, or

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Sep 2007 16:10:21 -0500

Nico
--

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Sep 2007 09:12:11 -0400

> section entitled "IANA Considerations" if there are no actions required

Your experience does not match what IANA has stated numerous
times. Please see section 6.1 of
draft-narten-iana-considerations-rfc2434bis-07.txt, which contains
text that IANA has a large part in crafting.

Thomas

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Sep 2007 09:27:13 -0600

> text that IANA has a large part in crafting.

By "my experience" I mean for example RFC 3922; during Auth48 or
thereabouts I was told that the IANA didn't want the document to include
an "IANA Considerations" section since there were no actions required of
the IANA. But perhaps that was a miscommunication.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Sep 2007 09:36:57 -0600

> the IANA. But perhaps that was a miscommunication.

Oh, and for what it's worth I agree with the policy of requiring an
"IANA Considerations" section even if there are no actions required of
the IANA, since I think it is best to be explicit about such matters.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tony Hansen <[email-masked]>
Date: Wed, 12 Sep 2007 13:34:07 -0400

My viewpoint is somewhat in between. The sections need to be there, but
only in the final draft(s) that are intended for Last Call. Prior to
that, those sections don't need anything more than a "To Be Determined"
notation. Prior to the Last Call, those sections usually don't add
anything to the technical meat of the draft and aren't necessary.
(Unless of course, the draft is dealing with IANA issues throughout.)

During Last Calls, there are many people reviewing the drafts from many
angles, including the protocol point of view and the IANA point of view
and the internationalization point of view and ....

	Tony Hansen
	[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Sep 2007 08:53:26 -0400

> the IANA. But perhaps that was a miscommunication.

To clarify, what happens during AUTH48 is mostly between you and the
RFC Editor. It's probably the RFC Editor that is calling for removal
of the empty IANA Considerations section. Going back the the very
first sentence quoted above, the specific question of what IANA wants
to see in an _ID_ is that they prefer a clear indication of what it is
they are supposed to do. An explicit "no IANA actions" statement in
the ID is preferred to "no mention of IANA at all", as the latter
increases the work for IANA to figure out what, if any, action it
has. Note that IANA typicall reviews documents during the Last Call
(or during the IESG Evaluation process), which happens prior to final
RFC editing.

Thomas

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Sep 2007 09:12:44 -0600

> (or during the IESG Evaluation process), which happens prior to final

Thanks for the clarification. That seems like the right approach to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/