The questions you refer to are not new. The same issues (IPR policy
conformance and hidden agendas) have been raised with respect to the
affiliations of ‘consultants’ who are hired by clients who wish to remain
anonymous. AFAICT, the IETF has never required that consultants divulge
their
Ted said:
If there are problems with the document, part of the adoption process should
be the identification of those flaws and an agreement to address them. So
bringing up those flaws during the adoption process is crucial to the process.
[BA] I would agree that there should be an agreement
Hadriel said:
I agree. My proposal for how/what/where to get more revenue (and not from
remote participants) was only in case we actually need it to pay for enhancing
remote participation. It's not clear we have such a need any time soon, but I
was only trying to provide an alternative model
The question is: this document is about an applicability update, not a
change of the on-the-wire behaviour of EAP.
[BA] That's right -- which is why I see no need for the applicability update to
depend on RFC 4282bis. It just needs to discuss the applicability aspects.
If we were to try
Sam said:
My recommendation is that we point out the issue. And say that
strings used within a specific EAP method MUST follow the rules
for that method. If AAA is used, strings used within AAA MUST
follow the rules for the AAA protocol in use. We can add an
informative citation to
[BA] Exactly. It's just an applicability statement, not a prescription
for world peace :)
Sure: we need more than an applicability statement update to achieve
peace in the EAP world. But if an applicability statement update is all
we can work with, we could try and do our best in that
Sam said:
We don't get to place requirements on applications except to say what
they need to do to use EAP. The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do
After reading this document, I believe that this document omits discussion of
an important aspect, which is internationalization. Since the contents of the
EAP Identity and RADIUS User-Name attributes are specified to be encoded in
UTF-8, application protocols that utilize encodings other
This is a note about two ongoing Call for Comments that may interest
participants on this list. Comments on these documents can be sent to
i...@iab.org or entered in TRAC.
1. Privacy Considerations for
Internet Protocols. This Call for Comment ends on February 18, 2013.
The document is
+1
[IAB Chair hat off].
Date: Fri, 11 Jan 2013 22:25:38 +0100
Subject: Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC
with Running Code) to Experimental RFC
From: abdussalambar...@gmail.com
To: s...@resistor.net
CC: ietf@ietf.org; i...@ietf.org
Hi SM,
I totally
[BA] The reply below represents my personal opinion.
Dave Crocker said:
It's true that this was not put into an Internet Draft. Apart from
that, we seem to be doing the right thing: - The IAB Chair announced
the text and the intent to sign it on 1 Aug.
Two weeks is normal process
Russ Housley said:
This is not an IETF problem, and I do not think that the IETF ought to
be discussing the internal workings of the ITU-T process. The point is
to come up with a mechanism that allows the code point to be assigned if
and only if the ITU-T does come to a consensus by whatever
Stefan said:
Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579.
[BA] Yes.
Stefan also said:
Interesting use. I
Stefan said:
My working copy has the following text in Security Considerations now:
If peer communication between two devices is configured for both
RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
shared secret security),and where the RADIUS/UDP transport is the
Stefan said:
That's true. As I went through your comments below, I realised that
large parts of the texts you quoted should be moved to the
dynamic-discovery draft altogether as they are are very specific to that
draft.
I'm thinking of taking out all the snippets you mentioned below,
transfer
This is a review of TLS Encryption for RADIUS draft-ietf-radext-radsec.
Overall, this draft was a pleasant to read, and it is clear that a lot of
thought as well as implementation experience has gone into it.
Kudos to the authors.
General Issues
There is a considerable amount of text
The document appears to contain typos in sections 4.16 and 4.17.
In section 4.16, it appears that Home LMA IPv6 address should be replaced by
Home DHCPv6 server address:
4.16. PMIP6-Home-DHCP6-Server-Address
0 1 2 3
0 1 2 3 4
Message-Authenticator should be mandatory (1 1 1 1).
On Jan 10, 2012, at 22:30, jouni korhonen jouni.nos...@gmail.com wrote:
Bernard,
Thank you for your review. See my comments inline.
On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote:
The document appears to contain typos
I've seen many enterprise customers using RFC 1918 address space internally.
This includes allocating 10/8 addresses for hosts, and 172.16/12 for isolated
segments behind firewalls. Since 192.168/16 may be used by employees in their
homes accessing the corpnet, often this block is avoided for
The same thought occurred to me. A very large enterprise will not utilize this
/10 on a whim; they'd talk to their ISP first. A consumer is unlikely to
modify the settings of their home router, except if they download malware that
does it for them :) and a consumer router vendor has such a
[BA] My comment is that having guidelines for this could help make the
advancement process more predictable. Thank you for working on this.
Jari Arkko said:
During the discussion of the two maturity levels change, a question was brought
up about DISCUSSes appropriate for documents that
Speaking for myself only, I believe that this proposal does attempt to address
some
issues relating to advancement, so that it is not entirely window dressing.
For example, I believe that the changes with respect to down references
(Section 4)
and annual review (Section 3) are
I reviewed the document draft-ietf-ecrit-phonebcp in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents
When I hear the term device identity spoofing, IEEE 802.1ar comes to mind
(see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf).
In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af, is
there a liaison contemplated to IEEE 802.1 relating to device identity?
Overall, I think this is a useful document.
My suggestions below mostly relate to potential organizational improvements, as
well as as a bit more detail in some areas.
Section 2
This section talks about how white-listing works, but does not talk about
potential mechanisms by which the
I reviewed the document draft-ietf-payload-rfc4695-bis in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents
I reviewed the document draft-ietf-mpls-ip-options in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents
There are two major issues remaining in this document.
One issue is that in a number of places, the document appears to
contradict IETF standards track documents.
Examples:
Section 3.1
If the client requires the use of the Keying-Material Attribute
for keying material delivery
I just took a look at the EAP EKE document recently approved by the IESG for
publication as an Informational RFC:
http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-09
The document does not define the following parameters required by RFC 5247:
1. Peer-Id
2. Server-Id
3. Session-Id
In
Dave Crocker said:
1. Can you provide some rationale for the details of the experiment?
2. Is one goal to maximize the attendance conflicts among BOFs?
1. In terms of rationale, I am reminded of Kinky Freedman's slogan, when
running for Governor or Texas: Why Not?
(see
BTW, IAB documents are now included in TRAC, so that it is now possible to
enter a comment or issue from the following link:
http://trac.tools.ietf.org/group/iab/trac/newticket
___
Ietf mailing list
Ietf@ietf.org
: Wednesday, September 22, 2010 9:35 AM
To: Bernard Aboba; Bernard Aboba
Subject: request: tsvdir for draft-gundavelli-v6ops-l2-unicast
Hi Bernard,
Can you do a tsvdir review for draft-gundavelli-v6ops-l2-unicast Last
Call ends 9/27
Thanks,
David Harrington
Director, IETF Transport Area
ietf
on
DNS lookups would not apply (or even make any sense).
-Original Message-
From: Stefan Santesson [mailto:ste...@aaa-sec.com]
Sent: Wednesday, September 08, 2010 7:21 AM
To: Bernard Aboba; daedu...@btconnect.com; ietf@ietf.org; stpe...@stpeter.im
Subject: Re: Review of draft-saintandre-tls
Peter said:
Aha, I see the source of confusion. I think the first sentence of Section 5.1
is better written as follows:
When the connecting application is an interactive client,
construction of the reference identifier SHOULD be based on the
source domain and service type provided by a
Peter said:
If that's the logic, I'd at the least like to see a 4985bis spec make
that clear, because IMHO it's not spelled out now.
RFC 4985 refers to authentication of service discovery in Sections 1 and 2.
Section 1 states:
This document specifies a name form for inclusion in X.509
That was in fact my original question.
Section 5.1 states that the source domain and service type MUST be
provided by a human user, and can't be derived. Yet in an SRV or
DDDS lookup, it is not the source domain that is derived, it is the
target domain. Given that, it's not clear to me what
Peter St. Andre said:
an SRV record can be used for two quite different purposes:
1. To point from an application service name to a particular host/domain name
in the same administrative domain (e.g., _imap._example.com points to
mailhost.example.com for its IMAP service).
2. To delegate an
I reviewed draft-saintandre-tls-server-id-check.
In a number of instances, this document is vague on the verification of an
SRV-ID, and in one instance, it appears to contradict RFC 4985, even though it
does not update that document.
Section 2.1 states:
o An SRV-ID can be either direct
In that scenario, it makes sense to me.
However, if the RA advertises the same prefixes would there be a reason to
mark all addresses as inoperable?
-Original Message-
From: Ralph Droms [mailto:rdroms.i...@gmail.com]
Sent: Thursday, August 19, 2010 2:50 PM
To: Bernard Aboba
Cc: IETF
Overall, I think the document the document looks good. Some comments:
Section 2.4
The host uses a combination of unicast
Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
and DHCPv6 message exchanges in order to determine whether previously
encountered routers
there was no implementation experience. Today recycling at
Experimental is pretty rare -- if there is motivation for a bis typically
this implies that there was interest/usefulness.
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Tuesday, June 22, 2010 1:00 AM
To: Bernard Aboba
Cc: ietf
Russ,
I'd also like to think you for revisiting this topic.
I support the recommendation to eliminate the Standard maturity level, and
also agree with your recommendation on Maturity Level 2 (similar to Draft
Standard).
We need more thought on what to do with the other levels though.
I reviewed the document draft-ietf-hip-hiccups-02.txt in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents
I reviewed the document draft-ietf-sip-domain-certs-06 in general
and for its operational impact.
--
Review Summary:
Intended status: Proposed Standard
This document describes how to construct and interpret certain
information in a X.509 PKIX-compliant certificate for use in a
Hadriel Kaplan said:
Howdy,
This may not be within the normal rules of etiquette, but I will re-iterate
my issues with this draft which I raised when it was discussed in RAI.
1) The mechanism does not scale, for large SSP's. (is this only meant for
small deployments?)
Expecting every
An editorial comment on Section 2.
Section 2
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. A Message-Authenticator
attribute MUST be included so as to provide per-packet authentication
and integrity protection. A
I reviewed the document draft-ietf-isms-dtls-tm-09.txt in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
I reviewed the document draft-ietf-l3vpn-mvpn-considerations in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
I agree with Dan. The added complexity seems to have very little if any
benefit.
Moreover, the existing IKEv2/EAP design has some very desirable cryptographic
properties (such as the ability to support
PFS even in situations where weak EAP methods are used) that could go by the
I reviewed the document draft-jabley-reverse-servers-01 in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
Roni Even said:
I do not think that the IETF should accept any work because people want to
do it, if this is the case a group of people can come and ask to start
working on any idea they have that has some relation to the Internet. IETF
should accept work that is in scope for of the IETF and
+1
On 5 Jan 2010 Patrik Falstrom wrote:
I agree with this.
On 4 jan 2010, at 23.40, Sam Hartman wrote:
I've been thinking about the codec issue for a while. I think it is
really desirable for the IETF to charter this group. I don't think the
charter should prohibit the working
I reviewed the document draft-lha-gssapi-delegate-policy-04 in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
Suresh said:
I will swap the text regarding SLLAO for 4.5.1 and 4.5.2. Does this work?
Yes. I think the changes got swapped, somehow.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ietf-dna-simple-09
I have reviewed draft-ietf-dna-simple. Overall, I believe this document still
contains significant technical issues that need to be addressed before
it would be suitable for publication as a Proposed Standard. In particular,
the version of the document sent
I have reviewed draft-ietf-idnabis-defs.Overall, I found the document
clear and easy to read.
Some specific comments below.
Technical
Section 2.2
When discussing the DNS, this document generally assumes the
terminology used in the DNS specifications [RFC1034] [RFC1035]
I reviewed draft-ietf-idnabis-tables-07.My comments are enclosed below.
Technical
Section 5.1
IANA is to keep a list of the derived property for the versions of
Unicode that is released after (and including) version 5.1. The
derived property value is to be calculated
I reviewed the document draft-ietf-dime-diameter-cmd-iana-01.txt in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
Steve Crocker said:
Are you suggesting the IETF is not mature enough to meet in China?
After watching this thread for a while, I am beginning to be convinced.
The IETF as an organization is mature enough to meet anywhere.
However, IETF participation is open, so that attempting to predict
The IETF does not and cannot make any warranties relating to the political
views, manners or behavior of attendees. The attendees are responsible for
their own actions, and the IETF has no ability ensure their conformance to
local laws or customers. If attendees violate the laws or customs
Yes, this looks good.
Date: Wed, 26 Aug 2009 22:36:42 -0400
Subject: Re: draft-zorn-radius-pkmv1-05.txt
From: d3e...@gmail.com
To: g...@net-zen.net
CC: bernard_ab...@hotmail.com; ietf@ietf.org; sec...@ietf.org
Looks OK to me,
Donald
On Wed, Aug 26, 2009 at 9:24 PM, Glen
Donald Eastlake said:
Doing a little more research, 802.16e-2005, which
you don't reference, does begin to touch on this by at least
specifying how EAP fits into 802.16.
[BA] As I understand it, this document is focused entirely on
PKMv1, which does not support EAP. So it does not apply to
Section 2.1
All SIP extensions considered in SIPCORE must be standards track.
Is this statement will really necessary in this document, or would it
be better suited for inclusion in the SIPCORE WG charter?
Typical IETF working groups do not live forever; SIPCORE's charter is
however
I also support publication of this document as a Standards Track RFC. A
substantial number of existing protocols (including TLS, EAP-TLS, PEAP,
EAP-TTLSv0, DTLS/SRTP and EAP FAST) already utilize the technology in this
document, which has proven quite useful.
Some technical comments on the document. Overall, I noticed that two
important capabilities are not currently supported:
1. Support for identity privacy. Currently the specification does
not support this, which could be a concern, particularly in Europe.
Privacy implies the
I also support publication of this document as a Standards Track RFC. A
substantial number of existing protocols (including TLS, EAP-TLS, PEAP,
EAP-TTLSv0, DTLS/SRTP and EAP FAST) already utilize the technology in this
document, which has proven quite useful.
RMS said:
How should an SDO respond? I'm not sure. I'm only sure that I don't like
getting DoSed, either into dropping a standard or into
not implementing it for fear of infringing.
[BA] A bit of history. While this draft generalizes the notion of a TLS key
material exporters, the
I believe the intent was related to RADIUS security. The guidelines
document could be updated to address this.
The rationale behind the original exemption was that security required
changes on both the RADIUS client and server. Therefore the RADIUS
server would need a code change anyway,
I would like to comment on the process aspect of this IETF last call. A
subsequent post will provide comments on the protocol.
Overall, I believe that the appropriate process for handling this document is
not to bring it to IETF last call as an individual submission, but rather to
I reviewed the document draft-ietf-sip-eku in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their
I reviewed the document draft-ietf-sip-eku in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring
I reviewed the document draft-ietf-speermint-requirements-07.txt in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on
New (Barnes):
A Device that conforms to this specification MAY omit support for HTTP
authentication [RFC2617] or cookies [RFC2965]. Because the Device and
the LIS may not necessarily have a prior relationship, it is RECOMMENDED
that that the LIS not require a Device to authenticate,
networks might choose to add this to their network design.
From: Bernard Aboba
Sent: Tuesday, 9 June 2009 5:48 AM
To: b...@estacado.net; ietf@ietf.org
Subject: Re: Gen-ART LC Review
ofdraft-ietf-geopriv-http-location-delivery-14.txt
Mary
Barnes said:
It
doesn't explicitly
Mary Barnes said:
It doesn't explicitly forbid the use of digest authn, but if it
can't depend on client support, then it can't really base any decision on
it.
The question isn't just about an authorization decision. There is also the
issue about what
the LIS is supposed to do with
Review of HTTP Enabled Location Delivery (HELD)
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery
As stated in Section 1 of the document:
This document describes a protocol that can be used to
acquire Location Information (LI) from a LIS within an access
network.
This
While I consider much of this document thoughtful and useful, there are a
number of assertions in Section 1 which concern me.
Section 1.2 of the document states that this document does not make a
recommendation with respect to publication requirements:
Any decision to make a Management
Henning said:
Before adding higher hurdles to the Proposed stage, maybe we can
identify whether such a mechanism would have solved real issues in
recent protocol design cases, or just delayed an already exceedingly
long process even more. Maybe BCPs imposing new requirements on WGs
need
The problem here is that a
consensus based approach is a lousy way to deal with large complicated
problems where the number of stakeholders is very large and only a
tiny minority of them are able to participate in the IETF process in
an effective manner.
This may well be true, but in many
Here is a dictionary definition of Beyond reproach:
Beyond reproach: So good as to preclude any possibility of criticism.
Last time I looked, RFC 3777 did not include this definition as a requirement
for the nomcom in selection of I* candidates.
Good thing, too. We seem to have gotten by
a
connection.
Bruce
On Sat, Apr 4, 2009 at 2:39 AM, Bernard Aboba bernard_ab...@hotmail.com
wrote:
Bruce Lowekamp said:
Many of the questions you raise point to the same question of whether
tests or techniques that are known to fail on a certain percentage of
NATs under a certain
Bruce Lowekamp said:
Many of the questions you raise point to the same question of whether
tests or techniques that are known to fail on a certain percentage of
NATs under a certain percentage of operating conditions are
nevertheless valuable. behavior-discovery has an applicability
statement
Cullen Jennings said:
I was somewhat shocked to see the draft in IETF Last Call. The last time this
draft was discussed at the microphone in Behave, many people were very
concerned that it id not possible to correctly characterize a NAT without using
more than one address behind the NAT. The
Thomas Narten said:
At the 20k level, I pretty much agree with everything John has said.
This smells to me mostly of a way for the IESG to have an friendlier
way of shutting down a WG without huring people's feelings. Sorry, but
I think this missed the point. (I would be fine with
To paraphrase Hamlet:
Hamlet: What's the news?
Rosencrantz: None, my lord, but that the IETF list's grown honest.
Hamlet: Then 'tis doomsday come.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I do not support publication of this document as a Proposed Standard via
the AD-sponsored route, for several reasons:
a. I believe that this document should have been handled as a WG work item.
It should not be commonplace for standards track security documents to be
handled outside
Thomas Narten said:
At the 20k level, I pretty much agree with everything John has said.
This smells to me mostly of a way for the IESG to have an friendlier
way of shutting down a WG without huring people's feelings. Sorry, but
I think this missed the point. (I would be fine with individual
I do not support publication of this document as a Proposed Standard, for
several reasons:
a. I believe that the subject of this document (TLS authorization) is of
fundamental importance to a number of IETF WGs, and therefore it should
not be handled via AD-sponsorship, but rather within a WG.
From my perspective, the best approach involves keeping the general
case simple. The documents that have been transferred outside the IETF
in the past five years is a single digit number, a tenth of a percent
of all RFCs if not a smaller fraction. From my perspective, the
simplest
Review of draft-ietf-trill-prob-05.txt
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their
Review of draft-ietf-monami6-multiplecoa-10.txt
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their
.Due to the ASCII character encoding being the core/monopoly
This is a bad start: non-ASCII characters are used on the Internet for
many years. There is certainly an ASCII *bias* in many Internet
protocols, applications or deployments but if there was an ASCII
*monopoly*, it ended a long
Single label names are local in scope. Attempting to use
them in a global context does not work. As the names in
. get more interesting the probability of collisions with
existing names goes up. Not many people choose two letter
labels for the least significant parts of their host names
Not really. ICANN isn't selling single-label domains. They
are selling (and I believe selling is probably now the correct
term) plain, ordinary, TLD delegations. If I get one of those
and populate the TLD zone only with delegation records, there
are no problems with what ICANN has done at
Lyman said:
I'm familiar with draft-klensin-rfc2821bis-10.txt and understand the
importance of using only FQDNs in SMTP exchanges given that [i]n the case
of a top-level domain used by itself in an email address, a single string
is used without any dots. What I'm interested in is
Mark Andrews said:
The Internet went to multi-label hostnames ~20 years ago.We added .ARPA to
all the single label hostnames as partof that process. The only hold over is
localhost andthat is implemeted locally, not in the global DNS. No sane TLD
operator can expect http://tld; or [EMAIL
We have a way to count DISCUSS positions, but we do not have a way to
figure out what percentage of them are perceived as late surprises
by the community. So, while we are taking action in an attempt to
make things better, we do not have a way to measure our success or
failure beyond
Russ Housley said:
I agree with this principle. In fact, I think that the IESG has taken many
steps over the last four or more years to reduce the nearly-end-of-process
surprises. Obviously, you do not think these measures have been sufficient. One
lesson from the many attempts to make
You may think I'm making light of this - and I am, because I think it's a
remarkably silly stance from the IESG - but if you can explain the
difference between rejecting all purple documents on Wednesdays and
rejecting documents that do not use RFC 2606, I'll be most grateful.
The
Glen Zorn said:
This all a matter of implementation stuff is just a cop-out: thisdocument
needs to clearly specify all the entities involved, howeverskeletal that
specification may be: if the RADIUS server gets thelocation information from
another server which subsequently validatesthe
1 - 100 of 240 matches
Mail list logo
