>>>>> "Ben" == Ben Campbell writes:
Ben> Hi, thanks for the response. Comments inline. I've removed
Ben> sections that do not appear to need further comment.
Ben> On Sep 17, 2013, at 1:29 PM, Sam Hartman wrote:
>>
genart&
Hi.
I somehow missed the genart review and Stewart kindly forwarded me a
copy
I will shortly be publishing a new version that includes fixes discussed
below.
> "genart" == Stewart Bryant writes:
genart> Major issues:
genart> None.
genart> Minor issues:
genart> -- This
> "John" == John C Klensin writes:
John> It seems to me that, in this particular case, too many people
John> are assuming a far more rigid process than actually exists or
John> can be justified by any IETF consensus procedure. Let's just
John> stop that.
I agree with John h
> "Black," == Black, David writes:
Black,> done. IMHO, we really should be setting a bar that says
Black,> that this sort of IETF imprimatur of approval of a crypto
Black,> algorithm actually means something.
Something got manged there.
I agree that publishing a standards-trac
> "Black," == Black, David writes:
Black,> done. IMHO, we really should be setting a bar that says
Black,> that this sort of IETF imprimatur of approval of a crypto
Black,> algorithm actually means something.
Something got manged there.
I agree that publishing a standards-trac
> "Black," == Black, David writes:
Black,> [A] Overall - I would like to see a paragraph added on how
Black,> this database conceptually relates to the IPsec Peer
Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3.
It doesn't.
not even a little bit.
It's not IPse
David, as we mentioned in the IESG thread, we seem to have dropped the
response to your comments about IANA actions.
WG:
>From the genart review:
[9] I suggest Expert Review for the new IANA registries, not just
First Come First Served, so that someone with a security "clue" can
check that the
Hi.
While I don't mind clarifying the server ID discussion, I don't see that
server ID has any relation to how the peer validates the name in the
server certificate.
Quoting section 7.6:
7.6. Server Certificate Validation
As part of the TLS negotiation, the server presents a certificate to
Danny sent me private text that he believes is better than what I
proposed.
I like your text below except that signing is the wrong word.
How about generation of integrity-protected messages?
These messages are almost never digitally signed.
Proposed text:
> Routers need to
> have tight
Hi.
Yes I'm making a last call comment on a document I edit:-)
During discussion of another document
)(draft-ietf-karp-crypto-key-table), a routing directorate review
brought up the concern that we don't talk about time synchronization.
Without time synchronization, the wrong keys can be selecte
Also, note that the important thing is not that applications use UTF-8
for usernames.
It's that they know what character set they are using and follow EAP's
(lack of) rules when using EAP.
In general, I would not expect an application to encode a username
that's also used in EAP authentication as
> "Stefan" == Stefan Winter writes:
Stefan> In the other hell, it can be sure to receive UTF-8 in NFC,
Stefan> and if that doesn't match what it needs, it can convert it.
Stefan> In my naïve thinking, that second hell is a lot less hot
Stefan> and much more habitable.
This
> "Stefan" == Stefan Winter writes:
>> However, I absolutely agree that if an application is going to
>> use EAP it needs to follow EAP's i18n conventions whatever those
>> may be. A rrequirement on anti-causal investigation for current
>> implementation efforts has never sto
> "Stephen" == Stephen Farrell writes:
Stephen> Hi Bernard, Patrik,
Stephen> Thanks for the comment. Checking that out now and will get
Stephen> back.
Bernard, thanks for the comment. I expected to feel really frustrated
at how late the comment was sent but after reading your
Hi.
As I mentioned in private mail, I think these are really great
documents and will work on learning the advice contained in them.
I hope we will all strive to pronounce names of contributors and their
companies as they would wish us to pronounce them.
I was wondering if call-chinese-names cou
> "John" == John C Klensin writes:
Strong agreement.
I'm not currently a member of that club, although if I stick around the
IETF long enough it's bound to happen.
I've certainly received and reviewed appeals that I thought were a valid
contribution to the process.
Don't appeal if there is
Please treat these comments as normal last-call comments.
I've been asigned as a security directorate reviewer for this draft.
This draft specifies a mechanism to indicate which packets were
discarded in a RTP stream. for the most part, this doesn't seem to have
any security implications, and
I'm fine with this text.
Either with eap-lower-layer as a MUST or the more complex version.
Joe, eap-lower-layer is not required for application authentication if
there's some other attribute that's specific to the lower layer. For
example Moonshot sends gss-acceptor-service-name but does not currently
send eap-lower-layer, and doing that seems consistent with the
requirements of the cha
> "Black," == Black, David writes:
Black,> The next to last paragraph on p.3 begins with this sentence:
Black,>For these reasons, channel binding MUST be implemented by
Black,> peers, EAP servers and AAA servers in environments where EAP
Black,> authentication is used to
I'm jumping into this particular branch of the conversation late. I've
followed Doug's concerns against DKIM somewhat over the years.
It seems fairly clear that Doug has a long-standing concern regarding
DKIM and how it interacts with e-mail.
It seems fairly clear he's in the rough within the IET
> "David" == Black, David writes:
David> Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David
David> L. Black Review Date: April 25, 2013 IETF LC End Date: April
David> 29, 2013
David> (Section 2)
David> [1] LocalKeyName and PeerKeyName are strings. What charac
> "Keith" == Keith Moore writes:
Keith> 2119 language is intended to describe requirements of
Keith> standards-track documents. Informational documents cannot
Keith> impose requirements.
i think using 2119 language in informational documents is often
appropriate and there are c
I'll say that about a year and a half ago I found myself pushing back on
discusses
that in my opinion clearly were not within the discuss criteria
significantly more than I ever had to do as an AD. My role was as WG
chair/editor.
Interestingly it's been less of an issue in my experience lately.
OK.
>1) this idea is baked enough for cross-area review to make sense.
>2) the protocol is not going to change significantly, one could
> implement.
>3) any future changes need thus to take into account impact on
> existing implementations... BUT that doesn't mean that we can't
> change thi
> "Michael" == Michael Richardson writes:
Michael> If we are unwilling to bring "RFC" back to a place were it
Michael> does not equal STD, then we need to create a new category
Michael> of document which amounts to "fully baked ID". Things like
Michael> IANA allocations coul
I think I understand this issue well enough to comment and so I will.
1) I totally believe it is reasonable to consider operational challenges
when designing protocols. "Just upgrade your infrastructure, just use
another registrar, just upgrade the infrastructure of the people you
communicate with
> "Brian" == Brian E Carpenter writes:
Brian> The null hypothesis would be that no significant differences
Brian> exist. If that turns out to be true, we know that our
Brian> problem is only lack of diversity among registrants. If it
Brian> turns out to be false, we know tha
> "Stewart" == Stewart Bryant writes:
Stewart> Why would you disregard a statistical analysis? That seems
Stewart> akin to disregarding the fundamentals of science and
Statistical analysis is only useful if it's going to tell you something
that matters for your decision criteria.
L
For what it's worth, I'm not finding the current discussion is providing
me useful information for making decisions. It doesn't really matter to
me whether the problem is selection of WG chairs or selection of
IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to
attempt to improv
Here are some quick initial responses to your comments.
Thanks much for the review and I'll follow up with more detail in a
while.
> "Black," == Black, David writes:
Black,> Major issues:
Black,> (Section 2)
Black,> [1] LocalKeyName and PeerKeyName are strings. What
Blac
> "Black," == Black, David writes:
I've been there too. I've had a number of recent discussinos with Pete
about what the IESG is and is not happy with .
I'll write something up and I'm sure he and the rest of the IESG will
let us know if we got it wrong:-)
> "RJ" == RJ Atkinson writes:
RJ> I oppose Eliot's proposed edits on grounds that they would
RJ> reduce the clarity of the specification and also would reduce
RJ> IETF and WG consensus about this specification.
Ran, I just checked, and you don't seem to be a 6man chair. We
gene
May I suggest that the specific details of this be left to the
implementation effort. What is easy to implement in this area depends
significantly on what platform (and here I mean more imap libraries and
imap server technology than say python vs ruby vs .net vs C) A simple
requirement like the im
> "Martin" == Martin Rex writes:
Martin> Oh, here is a message from the Security AD back then (Sam
Martin> Hartman), commenting on requirements for rfc2560bis (the I-D
Martin> under last call right now!):
Martin> http://www.ietf.org/mail-archive/web/pkix/current/msg03515.
> "Dave" == Dave Crocker writes:
Dave> Citing a 'contributors' section is invention on-the-fly. It's
Dave> not irrational, but it is not established IETF practice.
I believe contributors sections to be IETF practice.
As an example take a look at
http://www.rfc-editor.org/policy.h
> "Scott" == Scott Brim writes:
Scott> On 03/25/13 11:54, "John C Klensin" allegedly
wrote:
>> So perhaps a little more guidance to authors and WGs about
>> acknowledgments would be in order.
Scott> or a statement that acknowledgments is not a required section
Scott> an
Part of what I meant when I signed the diversity letter was to state a belief
that within a pool of qualified candidates, I believe diversity is
important enough that it is valuable to select for diversity even if
this does not maximize the skills that you enumerated (tech skill, admin
skill, works
Hi.
We've also created the trust-rou...@ietf.org mailing list to discuss the
effort.
--- Begin Message ---
The ABFAB working group has been busy at work describing a federated identity
and access management model that enables federated identity for a wide variety
of use cases and applications; t
> "John" == John C Klensin writes:
John> confidential or not) or getting into public discussions about
John> qualifications for a position while that position is under
John> active consideration by the Nomcom (not because the
John> qualifications should be an issue but because,
>Can you point out what is unclear?
margaret asked Russ whether we were talking about the future of the area
or n whether we were talking about requirements/expertise nomcom should
use for this year. After reading your message I still don't understand
which it is.
> "Michael" == Michael StJohns writes:
> dread a NomCom might face is the potential that the IAB may
> decide to exercise a line-item veto on nominated candidates
> - either forcing the NomCom to effectively start over, or
> giving the NomCom a clear indication that their effort to
> come up
> "Ted" == Ted Hardie writes:
Ted> I agree that the current language permits the current
Ted> operational model, because it leaves it up to the NomCom to
Ted> determine how to derive IETF community consensus; it can
Ted> believe the IESG is right,
Ted, up to here we're in ag
> "Dave" == Dave Crocker writes:
Dave> I agree it's not hairsplitting and that it is vitally
Dave> important.
Dave> Unfortunately, Sam, your model is simply wrong.
Dave> The IESG defines the job requirements. The Nomcom selects
Dave> according to those criteria.
Da
> "David" == David Kessens writes:
David> Sam,
David> Can we please stop the hairsplitting ?
David> It is not the IESG's fault if you feel that the nomcom is
David> taking the IESG input as absolute software style
David> 'requirements' as opposed to often more lightly in
> "Martin" == Martin Stiemerling writes:
Martin> Hi Margaret, I will answer as the agenda below is out of the
Martin> TSVAREA session.
Martin> On 03/07/2013 03:21 PM, Margaret Wasserman wrote:
>>
> Hi Russ,
>>
>> On Mar 5, 2013, at 11:18 AM, Russ Housley
>> wro
> "Jari" == Jari Arkko writes:
Jari> Sam, Thanks for raising this issue. The issue about what kind
Jari> of candidates are suitable for the task.
Jari> However, even if you asked us to not reply to your mail on the
Jari> public list, I wanted to do it for one aspect. I have a
> "Dave" == Dave Crocker writes:
Dave> And I have a further suggestion, which some other folk and I
Dave> happened to have discussed privately some time ago and
Dave> unrelated to the specific TSV situation...
Dave> There's an option available that the candidates might want
I have a huge number of concerns with Russ's message and am frustrated
and disappointed when I think about this year's nomcom process. I just
sent a message to the nomcom and iab about one of my concerns, and would
like to ask you whether you think you should do the same. I
specifically ask you
> "Russ" == Russ Housley writes:
Russ> Sam:
>>> So in conclusion, I strongly value technical contribution and
>>> demonstrated ability to pick up new knowledge in an AD. I do not
>>> highly value knowing all the things going on in a specific area
>>> at the time the AD joi
> "Mary" == Mary Barnes writes:
Mary> And, I continue to support Sam's position as well. To me the
Mary> question at hand is whether it will do more harm to fill the
Mary> position with someone that doesn't have the specific expertise
Mary> that his being sought than to leave
>>>>> "Eliot" == Eliot Lear writes:
Eliot> Sam,
Eliot> On 3/4/13 6:34 PM, Sam Hartman wrote:
Eliot> We're here because of the extremely specialized nature of
Eliot> transport. PhDs who specialize in it have gotten it wrong.
Eliot>
Brian> Russ, I would never argue for non-technical ADs. But when we
Brian> are short of candidates, it may be necessary to appoint
Brian> technically expert ADs who are not deep experts in the
Brian> specific area. It's a practical matter.
I actually think expecting ADs to learn a
I think tasking the IESG to look at how to reduce the time commitment
would be an incredibly good idea. I'd feel a lot more comfortable with
the community giving the IESG clear guidance that we'd like them to
solve that problem than with the community trying to come up with the
solution.
That sai
> "Lixia" == Lixia Zhang writes:
Lixia> 5218 is a general document; I believe what AB suggested is a
Lixia> historical record specifically for each WG: what you started
Lixia> with, what you went through, how you ended, what you have
Lixia> learned, both principles and lesson
> "SM" == SM writes:
SM> There are things that were said which were never done. There
SM> are things that were predicted and that never happened. Maybe
SM> it is because of process flaws. Maybe it is because it is
SM> easier to give up instead of trying.
Perhaps it's bec
> "Stephen" == Stephen Farrell writes:
Stephen> On 12/03/2012 02:50 PM, Barry Leiba wrote:
>> I'd really prefer if we'd talk about open source being desirable,
>> but not having it be necessary.
Stephen> Yep. I got another comment to that effect as well. I'll
Stephen> tr
Another +1 for prefering tools.ietf.org to ietf.org especially for the
wg pages.
The tools site is significantly more accessible than the IETF site.
One main reason is that the tools site actually uses html heading
elements. Screen readers can easily jump to headings, but I have to tab
through ever
> "Dave" == Dave Crocker writes:
Dave> On 11/28/2012 1:36 PM, Peter Saint-Andre wrote:
>> IMHO it is the chairs' responsibility to listen to the audio
>> recording and produce minutes from that (or at least check the
>> scribe's minutes against the audio recording). I've done
> "John" == John C Klensin writes:
John> Let me be clear. For most WGs and purposes, most of the time,
John> the "minutes" are the minutes and I'm certainly not going to
John> be the one who makes a big fuss about clarity or literacy
John> unless they are so incomplete and i
> "Carlos" == Carlos M Martinez writes:
Carlos> Sure! - ICANN (Adobe Connect, so far the best I've
Carlos> experienced)
I had my first Adobe connect experience today. I care a lot more about
accessibility than most participants do. On this metric Adobe Connect
seems to score very
> "Ted" == Ted Hardie writes:
Ted> I think the old catchphrase for this was "rule of law, not rule
Ted> of men", and I agree that there are fundamental benefits of
Ted> that approach. But the starting point of this discussion was
Ted> questioning why we seem to need process f
> "Ted" == Ted Hardie writes:
Ted> want to trust individuals as much as we used to. That lack of
Ted> trust isn't directed at the current IESG, IAOC, or IAB, but at
Ted> future incumbents. We have come to the idea that allowing a
Ted> current set of office-holders to make ad
I offer my signature to the recall petition. I am nomcom eligible.
At this point, I believe the recall process is the correct process to
follow unless there is an approved BCP update.
In a case where there's been no contact and there's an argument we've
found a gap in the procedures I can see the
> "SM" == SM writes:
So, I'm puzzled by this. my claim was that ISOC needed to approve
process related BCPs. If you take a look at RFC 2031, it supports that
claim. However, I'd kind of expect the other half of this to be in RFC
2026. I certainly recall us sending things like BCP 101 be
> "Michael" == Michael StJohns writes:
Michael> At 08:53 AM 10/25/2012, Noel Chiappa wrote:
>> We're all agreed that the IETF in plenary mode (i.e. all of us)
>> can change any/all policy/procedures, right?
Michael> Actually, that's my point here.
Michael> Once upon a ti
I'm supportive of ideas in this space.
I agree with Adrian that it would be far better to include someone that
some people don't recognize as influencing the community than to ever
get into an argument about excluding someone.
I am happy if others work out the details and trust to the community to
Pete, I have not been so frustrated and disappointed reading an IETF
message at any time earlier this year.
I'm disappointed because I'd like to work in an IETf climate where
antitrust and related concerns are taken seriously.
I need to believe that the IESG will take these issues seriously, will
Thanks. These are great responses, and I believe the FAQ would be
significantly improved by working these in.
Hi, Russ.
In question 2,
I don't understand what several terms are and whether they have any
relation to the standards process.
The one most confusing is "agreements to restrict output"
Also, more detail on what an anticompetitive reason to restrict someone
from the standards process could help.
Any advice from the SAML community on responding to the following
comment from Simon:
If the value is not simple or is empty, then the raw value(s) of the
GSS name attribute MUST be the well-formed serialization of the
element(s) encoded as UTF-8. The "display"
values are implementa
> "Richard" == Richard Barnes writes:
Richard> The security considerations in this document are difficult
Richard> to evaluate because the general architecture is unclear to
Richard> me, e.g., who attaches these names to things and who reads
Richard> them. (The naming scheme
> "Richard" == Richard Barnes writes:
Richard> I have reviewed this document as part of the security
Richard> directorate's ongoing effort to review all IETF documents
Richard> being processed by the IESG. These comments were written
Richard> primarily for the benefit of the
> "Joe" == Joe Touch writes:
Joe> On 9/5/2012 7:51 AM, SM wrote:
Joe> ...
>> Creating a perpetual I-D archive for the sake of rfcdiff is not a
>> good idea as it goes against the notion of letting an I-D expire
>> gracefully.
Joe> +1
Joe> Let's not forget there w
I strongly urge the IESG to be significantly more liberal in the cases
where an I-D will be removed from the archive.
I can think of a number of cases where I'd hope that the IESg would be
cooperative:
1) the IETF recieves a DMCA take-down notice or other instrument
indicating that a third part
hi. I regret having to do this. I realize the nomcom is important, and
it's a valuable way to contribute to the community. Unfortunately, I've
taken on some responsibilities since the nomcom call for volunteers.
I'm no longer sure that I will have the time to do as good of a job on
the nomcom as
I'd strongly prefer the IETF to focus on going to places where we get
work done and where costs can be controlled.
I'd prefer to avoid tourist destinations to some extent even if they are
not more expensive, but definitely if they are.
I want to present a professional image to my clients and I want
I'd probably also recommend excluding paid employees of ISOC. I cannot
really think of rationale that applies to the secretariat staff but not
ISOC.
> "David" == David Harrington writes:
David> The IETF could mandate a specific protocol to try to ensure
David> interoperability, but doing this takes the decision out of the
David> responsibility of the deployer to choose the best solution for the
David> deployment environmen
> "Stephen" == Stephen Farrell writes:
Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-)
Stephen> If I put in an RFC editor note adding a normative reference
Stephen> to the new EAP applicability statement [1] would that sort
Stephen> this out and not ca
Hi. I'd like to speak in favor of maintaining endpoint independent
filtering as the default and maintaining requirement 11 D. I think
requirement 11 D is important for avoiding some hard to analyze but
potentially very dangerous security problems. If I can trick a NAT into
replacing an existing ma
> "Simon" == Simon Perreault writes:
Simon> MUST NOT permit the lifetime of a mapping to be reduced beyond its
Simon> current life or be set to zero (deleted)
OK.
>> and MUST NOT support the third-party option.
Simon> I think pcp-base-26 added restrictions to THIRD_PARTY
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like a
> "t" == t p writes:
t> Just to make public what I have hinted at privately, I think that steps
t> in section 4.1 may be somewhat underspecified.
t> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos
t> information but the Security Considerations stress the
EAP (RFC 3748) has a applicability statement scoped very strictly to
network access.
This document provides a mechanism that falls well outside that
applicability statement and permits the use of EAP for general
application authentication.
When ABFAB was chartered, there was a charter item to u
I like Peter's rephrasing for a number of reasons.
1) Clearly states who is responsible for making the disclosure happen
(the IETf contributor)
2) Defines IETf contribution in its own sentence which makes it easier
to reference later.
3) Makes it clear that things like mailing list conversation
Add me as a +1 for the idea that content-type is important for this.
I tend to agree with the arguments given so far. Namely, for some
important use cases you're going to want to know the content type and
guessing is really a bad idea.
That said, there are security considerations associated with
--- End Message ---
--- Begin Message ---
On Wed, 2012-05-30 at 13:00 -0400, Sam Hartman wrote:
> I'd like to call the working group's attention to the new text
> surrounding RFc 2119 language. In particular in this draft, MUST
> features in the information model MUST be represe
[I'm going to forward Simo's original comments to the IETF list because
this doc is in IETF last call.
Here are my responses as chair.
]
> "Simo" == Simo Sorce writes:
Simo> 4.1.1.5. principalNumberOfFailedAuthenticationAttempts
Simo>This single-valued integer attribute contains
> "Russ" == Russ Housley writes:
Russ> Sam: I'm seeking clarity. Are you suggesting that the pre-WG
Russ> mail list ask this question while drafting the charter, or are
Russ> you suggesting that the IESG include this question in the call
Russ> for external review of the chart
I'd like to challenge the assumption that an explicit call for adoption
is required if work is mentioned in a charter. Sometimes, if work is
mentioned as a possible starting point, that's true. However for
working groups like the original XMPP, DKIM, ABFAB and BEEP, where work
was mentioned as a
> "Stephen" == Stephen Hanna writes:
Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily
Stephen> address almost all of the comments in my April 13, 2012
Stephen> secdir review. I do have one remaining substantive comment
Stephen> on this latest draft and two n
> "Adrian" == Adrian Farrel writes:
Adrian> How about... The key words "MUST", "MUST NOT", "REQUIRED",
Adrian> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
Adrian> "MAY", and "OPTIONAL" in this document are to be interpreted
Adrian> as described in [RFC2119] w
> "Joe" == Joe Salowey writes:
Hi.
I'm responding where I'm not able to just take Steve's changes.
Joe> Hi Steve, Thanks for taking time to perform a detailed review
>> In the Introduction, the second paragraph says that the problem
>> "results when the same credentials are used
For what it's worth, I support authors' (and this is actually one of the
few times I mean that rather than editors) right to make such a grant. I
believe the community is significantly better served by having
additional grants in the RFC, and strongly support us permitting them. I
believe our curre
> "Martin" == Martin Rex writes:
Martin> Joel jaeggli wrote:
>>
> Michael StJohns wrote:
> >
> > Martin - you and everyone else in the room gave permission by being
>> in > the room. That's what the NOTE WELL is all about. So no,
>> not illegal.
>>
>> Specifically
First, Steve, thanks for an excellent review.
You detected some really important fixes we need to make!
Hi. I'll respond in more detail later. I generally agree with Joe's
comments.
I want to respond to the IANA issues so Joe doesn't have to dig around.
Early allocation is a well-defined conce
Hi.
In the writeup I asked Stephen to include a note that there is a
normative downreference to RFC 4757. RFC 4757 is informational.
This document recommends that implementations not implement some of the
algorithms in RFC 4757, thus creating a normative down-ref.
My opinion and that of the WG is
> "IAOC" == IAOC Chair writes:
IAOC> QUESTION: What do you think about doing a Beer and Gear
IAOC> style of event on an evening that does not conflict with other
IAOC> IETF activities?
I think that hallway conversations, private meetings and other
activities that people have al
> "Russ" == Russ Housley writes:
Russ> Some suggestions have been made about the IETF mail lists.
Russ> There is a way for mailman to strip attachments and put them
Russ> in a place for downloading with a web browser. This would be
Russ> a significant change to current practi
1 - 100 of 782 matches
Mail list logo
