on, and if we don't do something official, well, there are some
people out there who were pretty peeved in Vancouver... and when we're
in *Texas*, there's no telling what they might do.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
... and the sessions often end early anyway, so
the extra session time is often wasted.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf
of the
WG and do not get out of hand.
I don't think that anything we say in the charter changes this; it is meant
to provide a guide for resolving the ratholes and distractions.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http
that the specifications
we're agreeing to use as a starting point be strong conflict-resolution
guides, and that they be used to steer the discussion... without making
it seem, incorrectly, that the WG is not willing to accept changes that
make sense to make?
Barry
--
Barry Leiba, Pervasive Computing
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
it. I think it will be
better to fight it later, if necessary.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf@ietf.org
https
in the formatting changes you're
looking at, at that stage?
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf@ietf.org
https
have already made those changes). I'm
wonder what sorts of things those are, and whether they're really worth
all the extra overhead.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
of complete
freedom.
--
Barry Leiba ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
it.
Barry
--
Barry Leiba, STSM, Internet Messaging Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
of is comprised of should be either comprises or
is composed of. The word comprises means is composed of, and that's the
correct usage (though it's a *very* common error, even among most native English
speakers).
Barry
--
Barry Leiba, STSM, Internet Messaging Technology ([EMAIL PROTECTED
Problem statement: IP source addresses can be spoofed. Packet delivery is based
only on destination addresses, to the spoofed traffic arrives, and hurts
(attacks/threatens) the destination. It'd be nice to stop the spoofing, and
existing solutions aren't sufficient.
There are product
Sorry; that got garbled by funny characters that came from copy/paste. Here it
is again:
Problem statement: IP source addresses can be spoofed. Packet delivery is based
only on destination addresses, to the spoofed traffic arrives, and hurts
(attacks/threatens) the destination. It'd be
Olaf, with a cast on his right hand, says...
There may be reasons to contact participants after a meeting, being able to
tie
the name to an e-mail might be of value.
I don't know what blue sheets *you* have looked at, but on the ones I've seen
I'd
say that most of the scrawling looks like
of www.ietf.org, they'll probably be
OK.
Please, I strongly urge you to at least make aliases so that the old
.../html.charters/WGNAME-charter.html links still work. There
really are links to them all over the place.
Thanks...
Barry Leiba
___
Ietf mailing list
On Mon, Jul 20, 2009 at 4:53 PM, Joel M. Halpernj...@joelhalpern.com wrote:
I think Harald's suggestion makes sense and should be implemented.
I agree.
Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of proposals aimed at extending a protocol,
it has opted to charter a working group to coordinate those proposals,
winnow them, and establish community consensus on which to
standardize, and how.
It should do that here, as well.
Barry Leiba
___
Ietf mailing
, in order to address some
of the points of most concern.
Barry Leiba
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
This crowd will appreciate this:
http://www.boingboing.net/2010/07/21/tcp-ip-and-tcpip-hea.html
--
Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I think Vancouver would be an excellent city for a recurring North American
meeting. There is a reasonable convenience factor in terms of nearby
hotels, restuarants and food markets (there's an excellent one just a couple
blocks from the venue). However, based on the poll, it seemed that
Hi, Peter. Thanks for the response, and I'm very happy with nearly
all the changes you've adopted. I'll not quote and comment on it all,
except to make the general statement: Great work!
I'd also like to take the security note from section 4.3 and echo it
here. So maybe this?:
The list
Tangent: I know we want to avoid implementations that do foolish things
being claimed as compliant, but IMO, the requirement that input come
from a human user is goofy for a technical specification and in
practice a non-starter. A web browser that followed a HTTP redirection
to a https: URL
A periodic call for comments, say at 2 and 5 years out, with those
judged to be still useful moving up the ladder,
for example?
I understand that objection based processing was not the most polite
way to word this in my draft,
and I'm sufficiently chastened to change it in the next
I'd like to hear from the community about pushing forward with this
proposal or dropping it.
I see disagreement with the proposal, but we'll see disagreement with
any proposal. I see enough support to continue pursuing it, in my
opinion, and trying to find a balancing point that enough of us
Scott, I'm confused about one thing you say:
On Tue, Oct 26, 2010 at 8:41 AM, Scott O. Bradner s...@harvard.edu wrote:
I think the community should only change its processes with careful
deliberation
taking into account the interplay of the different factors
...
I think it is better to not
Hmm. How many non-overlapping time slots? It would be extremely
frustrating if there was a lot of overlap between BOFs. Some of us
are interested in almost any new topic. My first reaction is to prefer
the BOFs spread out. I'm not sure that concentrating them will reduce
the problem of
# empty out toc.input
toc.input
# run once to get a sample ToC, but page numbers will be off
nroff file /dev/null 2 toc.input
# run again to get proper page numbers into toc.input
nroff file /dev/null 2 toc.input
# run a 3rd time to get the right output, ignoring stderr
Clarifying: the reason why I'm researching is that apparently some
people think it would be good to have a replacement for xml2rfc.tcl that
*emits* nroff (only - as opposed to plain text/nroff/html as the TCL
code does today).
Though I happen to like nroff (I also like anchovies) please
I'm sorry not to have posted this during WGLC, but I didn't notice it until now:
The document uses the phrase are advised [to do something] in two
places (the penultimate paragraph in Section 4.3, and the beginning of
Appendix D). I suggest that we either switch to 2119 language
(SHOULD [do
I agree that this needs tuning; but I'd rather not invent a new keyword for
that.
Sensible.
The appendix D
(http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-06.html#rfc.section.D)
isn't meant to be normative; thus I believe leaving it the way it is ought
to be ok.
OK.
I agree with you that it is really hard and even impossible to determine
what is going on in the Internet regarding some technology, protocol, etc.
If we set the impossible criterion for the Historic documents, this will
really make very few sense. So, as I have been pointed out, I find
Good; I've been suggesting this for some time also.
The IETF chair, the IAB chair, and the ISOC President/CEO may
delegate their responsibilities to other persons. The delegations by
the IETF chair and the IAB chair need to be confirmed by the IESG and
IAB respectively. The terms of
I'm very concerned about the IETF Chair getting decoupled
from the IAOC. The IETF Chair's job is a whole lot more than being
IESG Chair, and some degree of personal responsibility for oversight of
the administrative work seems to me to be appropriate.
So I'm not at all sure this delegation
I agree with Henk's modification -- in fact, my brain read it into it
already, which is why I didn't say it too. The delegation should only
be allowed to another member of the delegator's body.
I think you mean:
The delegation is for an one year term, aligned with the IAB and IESG
I was not assuming that delegation was limited to another member of the same
NomCom-reviewed body. One case was that you might delegate to a
NomCom-reviewed member who then leaves the NomCom-reviewed body. If the
NomCom-reviewed chair and the NomCom-reviewed body were OK with that person
This document is ready to go, modulo some nits.
Herein, my list of nits:
General
Because you define the terms, you should use them consistently.
Please check for Coordinator (replace with TZ Coordinator) and TZ
list (replace with TZ mailing list).
Sec 1.0
OLD
The TZ mailing list would fit
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.
I'm not sure whether I'm serious or not.
Whether you are or not.., the only way to do this is to stop calling
John said...
Well, you know, the Not a Standard But Might Be One Later really are
requesting comments.
Yes, well, we all know that RFC has lost any real sense of its
expansion long ago. It certainly has done so in the eyes of most of
the world, for whom RFC means Internet standard.
Dave
What is cron? and how does it interface with the originator defined as
the MSA? is cron an MTA or MUA?
...
It was a rhetorical question. I don't think its necessary and IMO,
unprecedented.
I'd be very surprised to find that mention of cron in an RFC is
unprecedented. Maybe I'll download
On Thu, May 12, 2011 at 8:38 PM, John Levine jo...@iecc.com wrote:
I'd suggest publishing it as Informational or Experimental rather than
BCP.
As DKIM chair, I'd like to reply to this and other messages in this
thread that discuss the status of the subject document:
There was extensive
As chair, I can say that consensus was to make this normative, not
experimental.
With the best will in the world, I was there, and I saw no such consensus.
We discussed it live at IETF 80, and I posted the following minutes to
the mailing list on 28 March:
3. Discussion of mailinglists
My understanding is that any RFC can be moved to Historic. But if this
is not clear from RFC 2026, maybe it is worth clarifying.
If 2026 doesn't limit what types of RFCs can become Historic, then I presume
any of them can. I'm not sure we need to make that explicit.
I'm sure we don't.
Purpose: Mailing list for proposed working group on FUture
home Networking (FUN)
And nothing more (same thing on the Web site). Could we ask
for a little bit more context when a new IETF list is created?
I think asking is perfectly reasonable. But I also think we
should trust the ADs who
On Thu, Jun 16, 2011 at 11:21 PM, Mykyta Yevstifeyev
evniki...@gmail.com wrote:
I have an only concern with regard to this document which I expressed
before, during WG discussions, and which I'd like to bring to IESG's
attention now.
For a number of times I proposed improving the control
More substantively, I fail to understand how this specification
proposes to create a class of reserved about: URIs when the about:
scheme seems to be internal information to an application. I think
the Security Considerations section doesn't address any of that, and
probably ought to,
Barry internally, and, therefore, has no interoperability
Barry requirements. As best I can tell, the issue here is to let
It does. It's an RFC1918-type use, and for the same reason we had to
document those networks, we have to document this URI.
This document prevents someone else
; Barry Leiba; iesg-secret...@ietf.org; Sean Turner
Subject: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys
Identified Mail (DKIM) Signatures) to Draft Standard
[...]
This indicates the DKIM specification is seriously flawed. While DKIM
may not offer author validation, it was intended
This document obsoletes RFC 4871 for which there is an IPR disclosure (
http://datatracker.ietf.org/ipr/1547/ ). As this is a move from Proposed to
Draft, is a new IPR disclosure required?
The disclosure you cite *is* the new one, which applies to the 4871bis
draft (disclosure 1547 updates
One final response from me to this, because it is relevant to the IETF
last call:
On Fri, Jun 24, 2011 at 1:33 PM, Douglas Otis do...@mail-abuse.org wrote:
Complaints from John, Dave, and Barry and others is likely and
understandably out of fatigue. They just want the process to be over.
No.
I am increasingly seeing IETF participants posting messages to IETF
mailing lists, sending messages to chairs and ADs, and so on, where
their messages include confidentiality/security/legal notices at the
bottom. You know the ones; here are excerpts from two recent
examples:
Hi, Jorge.
You may want to refer to Section 5.2 of RFC 5378, which addresses this
issue:
Each Contributor agrees that any statement in a Contribution, whether
generated automatically or otherwise, that states or implies that the
Contribution is confidential or subject to any privilege, can
Let me explain why I'm planning to include this sub-section.
Why? Your explanation lacks substance, and further effort here is a
waste of time.
The document as it stands is just fine, except for one sentence that
needs rewording to make sense in English:
OLD
All IONs were republished whether
Content-type: text/noise;
noise-type=bogus-legal-disclaimer, charset=...
Ooh, I like this proposal. We can also have noise-types for
exhortations to not print the email.
If one starts down that path, there is a real possibility for a
semantically-rich environment. For example,
Out of curiosity - why do we still see new drafts coming out, even -00 ones?
Some drafts don't get posted immediately
There also appears to be a bug, wherein the tool is not blocking late
submissions.
As we say, There are still a few bugs in the system.
Barry
Barry,
...
So, if only to increase my understanding, why do you think
reviewing this type of document (presumably through multiple
cycles as we quibble about language, etc.) is worth a Last Call
and the community's time?
John, you've mis-addressed this. It's Mykyta who wants to do it ,not
You're going to ask attendees to self-identify as tourists and leave
the room? Today's tourists may well become tomorrow's document
editors.
...
Let's just assign large enough rooms to BoFs and newly-formed WGs
so that the work can start in earnest.
I agree. If people are there paying
I think that it is an error for the IETF to add DKIM signatures. They do
indeed
tell me
which intermediary has sent me the mail, but does nothing for the 'spam' that
the
intermediary accepted in the first place (albeit there being little of that on
the IETF
managed lists).
...
It
On Mon, Aug 01, 2011 at 02:31:13PM -0400, Phillip Hallam-Baker wrote:
I suggest that this is a sub-optimal state of affairs. I see two solutions:
1) Codify the requirement that materials to be discussed at the meeting must
be submitted before the cut-off and that submissions made during
On Tue, Aug 9, 2011 at 1:16 PM, Martin Rex m...@sap.com wrote:
If one intends to actually *process* close to all of the Emails hitting
one's inbox in near real time, then List-Id:, and any pre-sorting based
on it, will _always_ slow down processing (unless the MUA or the processing
is flawed).
List-Id: is only useful for folks who have either lots of time on
their hands, or want to use automatic archival and have no desire
to actually process the email they're receiving.
...
I'm a simple human being that can focus his mind and his eyesight
only on one single thing at a time, so
Convincing the entire IESG is a very high barrier, especially when
typically, most of the IESG just wants the issue to go away. It might
happen for a significant architectural issue, perhaps, but not for an
area-specific technical flaw.
Here's the point: if an AD can't get at least one or
The problem is, the ADs are very busy people, and their expertise has to
cover a wide range of topics, so there will be few IESG members who can
really understand a subtle issue. Document reviews outside of one's
subject area are very difficult and require considerable focus. GIven
that,
Just responding to a small part, here:
B) RFC2119 states SHOULD is the same as the adjective RECOMMENDED.
As far I am concern, a recommendation is not a mandate nor obligation.
The problem we have with using what look like English words for these
things is that people have expectations
Mykyta says...
I personally use SHALL when
I mean it is to be so and not strict it is mandatory and obligatory and
compulsory and ... to be so.
But, see, this is exactly the sort of problem we're talking about.
You make some sort of semantic (not just stylistic) distinction
between MUST and
I'm in the group that likes this document, thinks it will help us move
forward, and thinks we should stop babbling and just do it.
That said, I have a issue with what Ross says:
Two things that I don't seem to have picked up on: (i) Any consensus that a 3
step
process is better than a 2 step
The IETF intends to provide a new tool to Working Group chairs and
Area Directors for the creation and updating of milestones for
Working Group charters. This document describes the requirements for
the proposed new tool, and it is intended as input to a later
activity for the design
-- Section 6 suggests side meetings should be (somehow informally) covered
by NOTE WELL. I think this is a very dangerous suggestion. The rest of the
document suggests that a side meeting has no official standing. That seems to
me to mean it's no different than a group of people who
This is truly a tricky point. Often, organizers of these bar BoFs
make great effort to get an AD involved and attending, make it clear
that they're having this because their BoF proposal got in too late or
was denied, and/or talk about a proposed WG charter. These side
meetings are often
but I guess I'm looking for a way that someone could
explicitly choose to have a meeting where Note Well did not
apply.
I think I disagree. I don't know what a decision to Not apply
the Note Well or, more specifically, to exempt oneself from the
disclosure requirements of RFC 3979, 4879,
1) Did the IESG consider processing this as RFC 3933 process experiment?
How on Earth could that possibly work?
First, simply the fact of the experiment will almost certainly prompt
people to participate, resulting in a number of specs upgrading from
PS to IS during the experiment... regardless
vCard 4 is the latest version, specified in RFC 6350. We'll make a note to the
RFC Editor to update the references.
There is an -01 version that makes this change and removes the
obsolete column in the IANA tables. I submitted it before the last
call went out, but I'm still waiting for the I-D
Please consider responding to the following survey, even if you did NOT
attend*.
...
It was originally sent to the 81all list, which is a bit preaching to the
choir (though it included those who pre-registered and didn't attend).
Though I find it interesting that, while 9 IESG members (60%)
SM says...
The short title of the draft is CFBL BCP. Given the recent short
discussion about the use of BCP, I suggest changing that.
Murray says...
Does the filename really matter?
He's not talking about the filename; the short title is what's printed
at the top of every page. It comes
He's not talking about the filename; the short title is what's printed
at the top of every page. It comes from the abbrev parameter in the
title element in the XML. It can be changed with an RFC Editor
note.
I'm certain MAAWG won't object to that change. Do I need to send the note?
No;
He's not talking about the filename; the short title is what's printed
at the top of every page. It comes from the abbrev parameter in the
title element in the XML. It can be changed with an RFC Editor
note.
The sponsoring AD would like to know what is desired in the RFC Editor note:
What
I'd still prefer s/the largest/a/ or s/the largest/a large/ or similar.
I suggest that J.D. leave it as it is, and let the IESG change it if
they think it should be changed. An RFC Editor note posted after the
telechat should take care of it, if that's what they decide, and Pete
is aware of the
Why not include the jabber logs the same way ?
The jabber logs are organized with one log per day, so figuring out the
right link based on the meeting number isn't perfectly trivial. Also,
I'm not sure those logs are used sufficiently often that such a link
merits a place in the regular
* All streams appear nominal audio quality wise.
What is this meant to mean?
Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
* All streams appear nominal audio quality wise.
What is this meant to mean?
Within expected paramaters... it's not like I generated MOS scores, but
they all sound pretty much like they should.
OK, I think I get you. All streams appear to be of reasonably good quality.
I was confused,
Please can everybody who doesn't upload PDF to the meeting materials page
at least take care to upload PPT instead of PPTX?
As a chair, I convert PPT and PPTX to PDF first, and always upload the
PDF. (And I ask participants to send me PDF in the first place.)
Some people prefer to send PPT(X)
The Datatracker does officially support PPTX, so I don't believe it's
unreasonable to use it.
By suipport it, you mean accept it and convert it to something
else, a meaning of support with which I'm unfamiliar. I'd say
tolerate. What's worse is that if you post PPT/X, it gets converted
not to
Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH].
The references to RFC 5598 and RFC 5322 should be normative.
I agree; I missed that in my shepherd review. So sorry.
A Verifier implementing both ADSP and ATPS SHOULD treat a message for
Errata 2684 was entered against RFC 5226, Guidelines for Writing an IANA
Considerations Section in RFCs. After discussion with one of the RFC authors
and IANA staff, I rejected the errata.
The errata author is saying that in many registries, there are no unreserved
values. For registries
In a small registry like this, it is useful to have something in the
box in the table that makes it less likely that the value will be squatted
on.
In the above example it is clearer in the 0..7 case that there are only
two free values and I will need a real good use case.
In the 0..5
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
draft-ietf-oauth-v2-23.txt as a Proposed Standard
There are some downrefs in this document that need to be called out in
the Last Call
On Thu, Jan 26, 2012 at 4:16 PM, SM s...@resistor.net wrote:
I have not seen any feedback from IETF participants affiliated with Huawei.
Hi.
I'm affiliated with Huawei. I'm a (recently added; see below)
co-editor on the two Sieve documents. I'm a chair of three working
groups.
I suggest that
I don't quite share the view that the license terms are not at
issue here. The reason that we have an IPR rule that asks us to
declare what the terms of a license are is so that the working groups'
members can evaluate both the applicability of the potentially
encumbering patents and the
browser id, openid, and oauth are all authentication frameworks built
on top of HTTP
OAuth is an authorization framework, not an authentication one. Please be
careful to make the distinction.
What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't
The MARF charter [1] does not contain any mention of SPF Authentication
Failure Reporting using the Abuse Report Format as a deliverable. There is
no mention of SPF in the charter.
Keep in mind that the charter has these two items:
2) The group will produce an informational document
I had expected that we'd deal with my shepherd review before doing the
last call on the document. Because that didn't happen, I'll re-post
my review here, as public last-call comments. Maybe that will prevent
people from raising the same things I've already raised.
First, two additional points:
current: The field is in current use
deprecated: The field is in current use but its use is
discouraged
The difference in current use can end up being problematic for the
designated expert.
A number of registries are using this wording already and there's been no
Security issues with respect to these reports are similar to those
found in [DSN].
The reference to DSN could be normative.
Security Considerations are never normative, so I'm not sure I agree
that this should be.
It should. Just because the Security Considerations section
This draft specifies a SMTP extension. The IANA Considerations does not
mention registration in the the SMTP Service Extensions registry.
It certainly does, in the first paragraph:
This specification requests IANA to add the PRIORITY SMTP extension
to the SMTP Service Extensions
to be made, and there is value in
implementing features from proprietary email systems in standardized
ways on the open Internet. The shepherd supports that general effort.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Barry Leiba is the document shepherd; Pete
Oh, it's absolutely true that if one is to define this sort of thing as a
combination of SMTP protocol and message header fields, that should be done
in a single specification. What I'm interested in community input on is
whether the mechanism of transferring the information back and forth
On Fri, Mar 2, 2012 at 6:47 AM, Hector sant9...@gmail.com wrote:
If I understand where you going with this, IMV, I don't think it is a good
thing SMTP systems should be expected will be processing the payload or its
headers before the EOD is issued.
This document doesn't specify anything that
Ned:
Another issue is the silly prohibition against using Priority: and other
header fields to set priority levels. What if is existing site policy is in
fact
to use those fields to determine message priority?
Alexey:
I actually don't have a strong feeling against usage of other existing
Other message header fields, such as Importance [RFC2156], Priority
[RFC2156] and X-Priority, are used inconsistently and often with
different semantics from MT-Priority. Message Submission Agents
[RFC6409] MAY use such fields to assign an initial priority in the
absence of an
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT,
I've used text like this before, and the IESG has never objected to
it. One advantage with this formulation, which uses the standard 2119
text and *appends* to it, is that idnits likes it and doesn't generate
a warning.
More generally, ID-nits is supposed to be helpful. Straightjackets are
1 - 100 of 262 matches
Mail list logo
