Ben == Ben Campbell b...@nostrum.com 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 hartmans-i...@mit.edu wrote:
genart -- This abstract claims
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 stbry...@cisco.com writes:
genart Major issues:
genart None.
genart Minor issues:
genart
John == John C Klensin john-i...@jck.com 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
Black, == Black, David david.bl...@emc.com 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
Black, == Black, David david.bl...@emc.com 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
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
Black, == Black, David david.bl...@emc.com 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.
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.
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
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie 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
Stefan == Stefan Winter stefan.win...@restena.lu 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
Stefan == Stefan Winter stefan.win...@restena.lu 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
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
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
John == John C Klensin john-i...@jck.com 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
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.
Black, == Black, David david.bl...@emc.com 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
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
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
David == Black, David david.bl...@emc.com 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.
Keith == Keith Moore mo...@network-heretics.com 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
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.
Michael == Michael Richardson mcr+i...@sandelman.ca 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
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 things.
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
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 david.bl...@emc.com writes:
Black, Major issues:
Black, (Section 2)
Black, [1] LocalKeyName and PeerKeyName are strings.
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
Stewart == Stewart Bryant stbry...@cisco.com 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
Brian == Brian E Carpenter brian.e.carpen...@gmail.com 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
Black, == Black, David david.bl...@emc.com 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 rja.li...@gmail.com 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
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
Martin == Martin Rex m...@sap.com 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
Scott == Scott Brim s...@internet2.edu writes:
Scott On 03/25/13 11:54, John C Klensin john-i...@jck.com 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
Dave == Dave Crocker d...@dcrocker.net 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
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,
Hi.
We've also created the trust-rou...@ietf.org mailing list to discuss the
effort.
---BeginMessage---
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;
John == John C Klensin john-i...@jck.com 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
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.
Martin == Martin Stiemerling martin.stiemerl...@neclab.eu 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
David == David Kessens david.kess...@nsn.com 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
Dave == Dave Crocker d...@dcrocker.net 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.
Ted == Ted Hardie ted.i...@gmail.com 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
Michael == Michael StJohns mstjo...@comcast.net 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
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
Dave == Dave Crocker d...@dcrocker.net 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
Jari == Jari Arkko jari.ar...@piuha.net 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
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
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
Eliot == Eliot Lear l...@cisco.com 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 One such person drove Van Jacobson
Mary == Mary Barnes mary.ietf.bar...@gmail.com 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
Russ == Russ Housley hous...@vigilsec.com 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
Lixia == Lixia Zhang li...@cs.ucla.edu 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
SM == SM s...@resistor.net 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
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie 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
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
John == John C Klensin john-i...@jck.com 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
Dave == Dave Crocker d...@dcrocker.net 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
Carlos == Carlos M Martinez carlosm3...@gmail.com 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
Ted == Ted Hardie ted.i...@gmail.com 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
Ted == Ted Hardie ted.i...@gmail.com 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
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 s...@resistor.net 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
Michael == Michael StJohns mstjo...@comcast.net 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
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
saml:AttributeValue element(s) encoded as UTF-8. The display
Richard == Richard Barnes rbar...@bbn.com 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
Richard == Richard Barnes rbar...@bbn.com 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
Joe == Joe Touch to...@isi.edu 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 was
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
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
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 ietf...@comcast.net 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
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie 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
Simon == Simon Perreault simon.perrea...@viagenie.ca 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
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
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
t == t p daedu...@btconnect.com 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
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
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
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
[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 s...@redhat.com writes:
Simo 4.1.1.5. principalNumberOfFailedAuthenticationAttempts
SimoThis single-valued integer attribute
---
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 representable in schema *and*
MUST be supported by all implementations
Russ == Russ Housley hous...@vigilsec.com 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
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 sha...@juniper.net 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
Adrian == Adrian Farrel adr...@olddog.co.uk 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] when they
Joe == Joe Salowey jsalo...@cisco.com 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
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
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
IAOC == IAOC Chair bob.hin...@gmail.com 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
Russ == Russ Housley hous...@vigilsec.com 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
Your proposed direction for trust validation semes like a major
improvement to me.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi. I'm not the secdir reviewer assigned to this draft, but felt that
this draft needed additional security review, so I decided to perform a
secdir-like review.
Overall, I think this is a much-needed specification and believe it is
mostly ready for publication as an experimental RFC. I'd say a
Brian, I'd like to join this from another angle.
What exactly does changing your v4 address get you in terms of privacy?
It's my understanding that protocols including TCP, HTTP, TLS, and very
much the web platform are fairly easily linked.
That is, it's relatively easy to determine with
1 - 100 of 746 matches
Mail list logo
