I support the general approach you outline in terms of process.
However it would really help me if you could write a non-normative
paragraph describing what you think is involved in an anti-trust policy?
___
Ietf mailing list
Ietf@ietf.org
Russ == Russ Housley hous...@vigilsec.com writes:
Russ Sam: I looked at the antitrust policies of other SDOs. They
Russ state the things that are prohibited from discussion at their
Russ meetings and on their mail lists.
OK, that sounds good. I definitely think we could use such a
Michael == Michael Richardson m...@sandelman.ca writes:
Michael I'm still lost.
Michael What kind of things would the IETF have to prohibit
Michael discussion of, and specifically things that would involve
Michael anti-trust.
Cisco and Juniper folks form a design-team
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 10/21/2011 7:58 PM, Melinda Shore wrote:
It's increasingly the case that if you want to do work at the
IETF, you need to go to meetings. I'd have considerable
reservations about asking for the kind of money you're
Olaf == Olaf Kolkman o...@nlnetlabs.nl writes:
Olaf Dear Colleagues,
Olaf I have just chartered a very short draft that intends to
Olaf update BCP101. It can be found at:
Olaf http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
Olaf The draft is very short
I think the draft would be improved by explicitly considering these
issues and not remaining silent, even if the decision is to say that
these are full members; existing processes for recall etc apply; at the
time of writing that means blah. I think that would lead to better
discussion and review
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 9/19/2011 8:35 AM, Spencer Dawkins wrote:
Anything that the IETF can do, to make the IAB and IETF Chair
positions less of a full-time (or more) job, is a good thing.
Dave Anything? I believe you do not believe that
Keith == Keith Moore mo...@network-heretics.com writes:
Keith 2) This will not do any good
Keith IMO, that is a valid objection. Stability in our process is
Keith desirable; therefore change merely for the sake of change is
Keith undesirable.
This will not do any good,
Hi. I feel it's reasonable for me to speak up since I have not done so
in over a year on this document so my opinion probably has not been
counted.
1) I support moving to a two level process.
2) I've generally supported versions of this document I have read. I
have not read this version in
Eric == Eric Burger ebur...@standardstrack.com writes:
Eric This highlights an interesting issue as an RFC goes from PS to
Eric IS. I would offer that most SHOULDs in a document will, if
Eric there are real implementations out there, migrate to MUST or
Eric MUST NOT.
Eric On
gareth.richa...@rsa.com writes:
Why should we require that alg-ids be registered URIs?
That's not my concern - the existing first paragraph of the IANA
considerations section in the draft requires IANA registration
(or at least tries to) by pointing to the PSKC
What information required by the PSC registry do we not need?
The only thing I see is the XML information, but it looks like that
could be blank.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Henry == Henry B Hotz h...@jpl.nasa.gov writes:
Henry I was thinking that if it's a proprietary OTP, we can still
Henry use it even if the algorithm is secret. If we know we're
Henry getting a clear text OTP value and we have an (unspecified)
Henry method of verifying it against
gareth.richa...@rsa.com writes:
Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana?
We could do that. Doing so would be a very inefficient way of moving
the OTP document forward. I'd recommend that we use an existing
registry. If we cannot do that, we'll need to do the
Hadriel If we use actual *attendance* as a form of voting,
Hadriel Minneapolis would lose big time.
I don't think using actual attendance is the right metric. Actual
attendance of people who submitted internet drafts or chaired meetings
would be closer, but is also problematic.
My goals
Melinda == Melinda Shore melinda.sh...@gmail.com writes:
Melinda On 08/24/2011 07:47 AM, Keith Moore wrote:
Maybe they don't realize it, but at that point they're actively
working to exclude participation from those not supported by
large companies or governments.
Melinda
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave ps. As a personal aside, I'll note that I've lobbied rather
Dave vigorously for venues that entail less travel effort, by
Dave eliminating the additional hop needed to get from a major hub.
Dave Note that that has gotten
david.bl...@emc.com writes:
[1] In section 6.1 at the top of p.28, I don't believe that the
use of lower case recommended is a strong enough warning about
the danger in using anonymous PKINIT because it exposes the OTP
value:
It is therefore recommended that
SM == SM s...@resistor.net writes:
SM There is currently a DISCUSS for draft-ietf-yam-rfc4409bis-02:
SM process weenie=
SM The IETF LC
SM
(https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=9680tid=1314107697)
SM did not call out the downrefs to RFC 4954 and 5321.
Greg == Greg Hudson ghud...@mit.edu writes:
87
Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there appears to
be no other way for them to
My take as an individual is that most of the people who have read the
draft and commented here read it the same way. It's up to the AD to
decide if things are clear enough but I'm not pushing for any specific
change and would be happy if no change were made on this point. I would
not push back
Simon == Simon Josefsson si...@josefsson.org writes:
Simon Sam Hartman hartmans-i...@mit.edu writes:
Actually, I have a question about interoperability here.
It's my assumption that a client of this specification needs to
implement basically all the options
Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for
consistency with draft-ietf-karp-ospf-analysis. KARP is chartered to
figure out what improvements we need in routing protocol
authenticationq. While draft-ietf-karp-ospf-analysis has not been
approved by the WG, I think it's
and a
timestamp.
This change has already reached consensus within the working group. If
there are no objections (especially including objections from our AD)
I'll ask the authors to make this change. If there are objections then
our AD will judge consensus as usual.
Sam hartman
Kerberos Co-chair
Brian == Brian Weis b...@cisco.com writes:
Brian Hi Sam, Thanks for your review.
Brian Your first comment is pointing out a typo (groupkey-pull
Brian should be groupkey-push), which I've fixed.
Brian The anti-replay description in Section 3.3 should not say
Brian that the
This update to the GDOI specification significantly improves clarity and
readability.
However, there is one issue that I think should be addressed prior to
publication:
At the top of page 11, the spec claims that a seq payload protects
against group members responding to groupkey-pull messages
I think removing the cutoff is the right approach here.
I'd prefer that some date remain on the list of important meeting dates
to remind ourselves that revisions should be in in time for people to
read them.
___
Ietf mailing list
Ietf@ietf.org
Keith == Keith Moore mo...@network-heretics.com writes:
Keith On Aug 1, 2011, at 3:59 PM, Sam Hartman wrote:
I think removing the cutoff is the right approach here.
I'd prefer that some date remain on the list of important meeting
dates to remind ourselves that revisions
I'd prefer that we not clutter abstracts with instructions to the RFC
editor and prefer that the IESG only recommend such statements in the
introduction.
I'm OK with whatever here though: the IESG should go do something
intelligent in this space.
___
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages, and are
Stephen not stored in the repository.
Stephen == Stephen Kent k...@bbn.com writes:
Stephen At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new
Steve, I'd like to thank you for working through these issues with me.
I think the new texxt you added before approval is very helpful. You
indicated you could add an additional sentence pointing out that
multiple signed objects would need to be used in order to deal with
phase 2 for end-entity
Let me make sure I'm understanding what you're saying. I can have
multiple ROAs for the same set of prefixes in the repository and valid
at the same time: one signed by a new certificate and one signed by a
previous certificate? If so, I think I now begin to understand why the
SIDR working
Stephen == Stephen Kent k...@bbn.com writes:
I guess the only question I'd have remaining is whether ROAs or
other signed objects are intended to be used in other protocols
besides simply living in the SIDR repository?
Stephen The RPKI repository is designed to support
Steve, thanks for your note.
I realize the certificate resource profile document has been approved,
but I'd still like to understand what is happening here.
I'm having trouble reconciling the new text you've added to the
document with draft-ietf-sidr-signed-object.
2- During phase 2
Russ == Russ Housley hous...@vigilsec.com writes:
Russ The 6 months starts with RFC publication.
Please say that in the draft then.
I had a different take away from the last version of this discussion I
participated in.
I don't care much what the answer is, but it seems clear that it
At the mic at the technical plenary last night, I made a comment that I
strongly supported the IETF doing API work.
I've realized that people may have assumed I meant that it would be
appropriate for the IETF to specify an API and not a protocol for some
given task.
That's not what I meant, so
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 3/29/2011 10:13 AM, Sam Hartman wrote:
At the mic at the technical plenary last night, I made a comment that
I strongly supported the IETF doing API work.
I've realized that people may have assumed I meant
Marc On 03/29/2011 01:28 PM, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one
open source implementation? That effort would produce a de facto
API.
Marc What you need is a reference implementation (i.e. an
Marc inefficient but
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
Paul == Paul Hoffman paul.hoff...@vpnc.org writes:
Paul On 3/10/11 9:37 AM, Sam Hartman wrote:
The document also requires that relying parties reject
certificates that include unknown extensions. The rationale
explained in section 8 is that it is undesirable to have
Paul == Paul Hoffman paul.hoff...@vpnc.org writes:
Paul I don't think either of us is missing something, we just
Paul disagree about what needs to happen if a fix that changes the
Paul semantics of the certs needs to be made to the system as a
Paul whole. For changes that don't
Cullen, there's a lot of history with port registrations. As you're
probably aware in the past, there was a procedure for experts to sign an
NDA before reviewing port requests. It's my understanding that is no
longer done. However, it does suggest there's strong desire for
proprietary protocol
Joe == Joe Touch to...@isi.edu writes:
Joe On 1/27/2011 12:52 AM, Lars Eggert wrote:
Joe ...
Small Issue #3: I object to anonymous review
The current review is anonymous and this draft does not seem to
change that. I don't like anonymous review - it's not how we do
Joe == Joe Touch to...@isi.edu writes:
Joe On 2/1/2011 11:14 AM, Sam Hartman wrote:
Joe ...
Joe, the IESG had a fair amount of negative experience with this
style of review just before I joined; this type of review was
just about out of the process leading to blocking
Dale, I agree! I think the bar of producing an internet draft is low
enough. Regardless of what mechanisms we adopt to give people a chance
to try and sell their drafts, I think it is critical that we require the
drafts to be written. I'm not really interested in lowering the bar too
much for
Martin == Martin Rex m...@sap.com writes:
Martin Sam Hartman wrote:
I'm OK with this text. I tried to come up with a way to briefly
discuss how error detection is very related to things like
protecting against substitution of content (the internet mirror
case
I'm OK with this text. I tried to come up with a way to briefly discuss
how error detection is very related to things like protecting against
substitution of content (the internet mirror case) but failed to come up
with something brief.
So, I'm fine with what you have.
--Sam
Francis == Francis Dupont francis.dup...@fdupont.fr writes:
Francis In your previous mail you wrote:
FrancisI'm OK with this text. I tried to come up with a way to
Francis briefly discuss how error detection is very related to
Francis things like protecting against
Radia == Radia Perlman radiaperl...@gmail.com writes:
Radia No objections. Radia
Can I get someone to confirm that the text in the proposed sentences is
substantially true?
I think so but I'm not an IS-IS expert.
___
Ietf mailing list
Donald == Donald Eastlake d3e...@gmail.com writes:
Donald Hi,
Donald On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman
hartmans-i...@mit.edu wrote:
Radia == Radia Perlman radiaperl...@gmail.com writes:
Radia No objections. Radia
Can I get someone
Hi. I've been asked by the trill authors to clarify what I meant by my
secdir review.
That's certainly fair.
I think there are two issues.
The first is that I think that draft-ietf-isis-trill does an adequate
job of discussing the security implications of IS-IS on trill. I've
read the
Adrian == Adrian Farrel adrian.far...@huawei.com writes:
Adrian Sam, Thanks for your work.
Adrian Can I clarify. You wrote:
The first is that I think that draft-ietf-isis-trill does an adequate
job of discussing the security implications of IS-IS on trill.
I've read the
Erik == Erik Nordmark nordm...@acm.org writes:
Erik Adding just this sentence to draft-ietf-isis-trill (the code
Erik point document) seems odd. Your comment is really a comment on
Erik the security of IS-IS, and not specific to TRILL and unrelated
Erik to the code points.
I
Please treat these as normal last call comments.
I found the introduction to draft-ietf-isis-trill inadequate. I'm
familiar with the base concepts behind TRILL, roughly understand what
was going on and followed the chartering discussions of the WG fairly
closely. I have read the requirements
So, I'm sympathetic to the idea that we in the security community can be
overly paranoid. however I'm more sympathetic to the idea that it's
hard to figure out what uses are security sensitive and what uses are
not. At least in the case of md5, where backward compatibility concerns
don't dictate
Bob == Bob Braden bra...@isi.edu writes:
Bob On 9/8/2010 3:12 PM, Richard Bennett wrote:
It seems to me that one of the issues here is that architecture
models are published as Informational when they're clearly not in
the same level of authority as most Informational RFCs. An
Noel == Noel Chiappa j...@mercury.lcs.mit.edu writes:
I suspect that a more nuanced analysis would have this as 1.7 and
shrinking : 1 and stable : 1 and stable.
Noel and his conclusion:
I would support 2:1:1 for the present, with an intention to review that
in 2-3
Bob == Bob Hinden bob.hin...@gmail.com writes:
Bob A question for you. Should we select meeting venues to
Bob minimize the cost/time/etc. of all attendees or just, for
Bob example, w.g. chairs? Many people have suggested that the IAOC
Bob should be looking at overall attendee
Brian == Brian Weis b...@cisco.com writes:
Brian There is an I-D for one GKMS (draft-ietf-msec-gdoi-update-06)
Brian that includes support for SIDs which could be referenced. It
Brian is expected to head to WGLC soon. Would citing that document
Brian address your concern?
A
This is a secdir review of the above draft.
The text looks fine. However, I'm concerned that this specification does
not provide sufficient detail for interoperable implementation. It
makes it clear that a GKMS needs to allocate SIDs but does not cite any
mechanism for a GKMS to do so.
I
Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the
design of a GSS-API mechanism.
I think this is a good start but is not quite done yet.
draft-hartman-gss-eap-naming-00 discusses a couple of problems with
naming extensions:
* The format of attribute names proposed in this
Iljitsch == Iljitsch van Beijnum iljit...@muada.com writes:
Iljitsch On 7 jul 2010, at 17:23, John Morris wrote:
Well, as someone who believes that *all* websites and
online-operating organizations should have a clear and accessible
privacy policy, I think it is beyond
Ole == Ole Jacobsen o...@cisco.com writes:
Ole Sam,
Ole I view this more or less as standard boilerplate, something
Ole you find in a lot of online places. I think it is reasonable
Ole to expect that if you register for a meeting your personal info
Ole (e-mail address
John == John Morris jmorris-li...@cdt.org writes:
John Paul, Sam, I understand your arguments to bascially be we've
John never had an internal privacy problem here at the IETF, and as
John far as I know no one decides not to participate because of the
John lack of a privacy
Hi. I'd like to announce that there will be a BOF on federated
authentication beyond the web at IETF 78. we'd like to form a working
group to standardize protocols for federated access to applications that
are not browser based. Targets include think client applications and
some
Alexey == Alexey Melnikov alexey.melni...@isode.com writes:
Alexey Sam Hartman wrote:
Jiankang == Jiankang YAO ya...@cnnic.cn writes:
Jiankang If there are many things we must do, we(WGs) normally
Jiankang prioritize the things. sometimes, the easier one first
Jiankang == Jiankang YAO ya...@cnnic.cn writes:
Jiankang If there are many things we must do, we(WGs) normally
Jiankang prioritize the things. sometimes, the easier one first;
Jiankang sometimes, the difficult one first.
Sure.
That's fine for the WG to do.
I don't think it is good
IETF == IETF Administrative Director i...@ietf.org writes:
IETF 9. Members shall at all times act in a disinterested manner
IETF and consider only the benefit to the IETF standards process
IETF and community as a whole in discussions and decisions. The
IETF Members shall promptly
Peter == Peter Saint-Andre stpe...@stpeter.im writes:
Peter On 5/19/10 12:36 PM, Sam Hartman wrote:
I believe that without explicitly listing the use cases I've
brought up in the body of the charter, the additional paragraph
Peter I proposed:
PeterAlthough the group
I believe that without explicitly listing the use cases I've brought up
in the body of the charter, the additional paragraph would be a
significant step backward. I would object to chartering the group with
that paragraph added without explicitly listing any use cases including
the onse I brought
Hi.
I think there are two items that should be considered with the scope of
this working grou.
The first is RFC 4282. RFC 4282 section 2.4 discusses
internationalization strategies based on stringprep and IDNA2003. It
does not define its own profile. Apparently, in addition to all the
Marc == Marc Blanchet marc.blanc...@viagenie.ca writes:
Marc we had a discussion about the same subject: i.e. should we
Marc restrict the scope to a specific set of documents to
Marc review/update/... or do we keep some provision for other
Marc documents coming in the stream that
I fairly strongly support the IESG's proposed policy statement on the
day pass experiment. I specifically belive that it is counter to our
ability to fund our ongoing activities to turn the day pass experiment
into a way to reduce the cost of attending IETF on an ongoing basis. We
want to do
Simon == Simon Josefsson si...@josefsson.org writes:
Simon This document appears to have a normative reference to a
Simon patent:
Simon[LUHN] Luhn, H., Luhn algorithm, US Patent 2950048,
Simon August 1960, http://patft.uspto.gov/netacgi/nph-
Simon
Folks, I'm looking forward to seeing some of you at the bar bof on
federated authentication for non-web applications this evening at 9 PM
in the Manhattan room. Please see
http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
detailed reading list and remote participation instructions.
I have been assigned this draft as part of the secdir review process. I
see no security issues with the draft that are really within the scope
of a secdir review.
I do have significant concerns I'd like to raise as last call comments.
In general, I agree with most of the concerns raised about
I'll say that I'm in category c: the format issue matters a lot to me
and I prefer the status quo.
Changing the format issue is difficult, people who want to change it
routinely ignore some of the issues, and neither side participates in a
constructive discussion.
The status quo is acceptable and
Andrew == Andrew Sullivan a...@shinkuro.com writes:
Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote:
That seems to cover most angles. I can't see why the IESG could
be expected to add technical disclaimers to a consensus
document. In fact, doing so
of the proposal see
http://www.ietf.org/mail-archive/web/emu/current/msg01363.html
and for our mailing list see
http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY
Thanks for your interest,
Sam Hartman
Painless Security, LLC
___
Ietf mailing list
Glen, I have to agree with Dorothy's comment. This method should
provide for channel binding support. I find your unsubstantiated
assertion that doing so wouldbe be absurd uncompelling.
You claim that channel bindings are poorly defined. I believe that
draft-ietf-emu-chbind brings us most if
/moonshot1
You can find the feasibility analysis at
http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf
Thanks,
Sam Hartman
Painless Security
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman
Peter == Peter Saint-Andre stpe...@stpeter.im writes:
Peter On 1/7/10 9:46 AM, Russ Housley wrote:
Andy:
Although this preference cannot guarantee that the working
group will produce an unencumbered codec, the working group
shall attempt to adhere to the spirit of
Roni == Roni Even ron.even@gmail.com writes:
Roni Hi, I do not think that the IETF should accept any work
Roni because people want to do it, if this is the case a group of
Roni people can come and ask to start working on any idea they have
Roni that has some relation to the
Olafur == Olafur Gudmundsson o...@ogud.com writes:
Olafur There is one case where knowledge and special handling of
Olafur the name may cause problems: DNS Liers i.e. specialized
Olafur DNS resolvers that make all non-existing name exist that do
Olafur not generate lie for
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 group from selecting some existing
codec nor should it prohibit doing new work in this space.
I'm not really particularly happy with Joe's two recent DNS drafts.
They give me the impression as a reader that a lot of context is being
hidden from me and that the implications of the draft are being
carefully obscured so that I as a reviewer not involved in the process
won't know what is
Joe == Joe Abley jab...@hopcount.ca writes:
Joe On 2010-01-04, at 14:43, Sam Hartman wrote:
I'm not really particularly happy with Joe's two recent DNS drafts.
Joe If I can help clarify anything, please let me know.
So, I think John is asking the questions well about the in-addr.arpa
Julian == Julian Reschke julian.resc...@gmx.de writes:
Julian Marshall Eubanks wrote:
... This message is to announce that the IETF Trustees have
adopted on a new version of the Trust Legal Provisions (TLP), to
be effective 28 December, 2009. The Grace period for
Richard == Richard L Barnes rbar...@bbn.com writes:
Richard Here's (what the ITU claims is) the specific proposal that
Richard has been made to the ITU: An ITU spokesman said: The ITU
Richard has no plans to modify the BGP protocol, which is not an
Richard ITU-T standard. A
Olivier == Olivier MJ Crepin-Leblond o...@gih.com writes:
Olivier Ole Jacobsen o...@cisco.com wrote:
(except it's not a joke)
Olivier As someone who has confronted some of these gentle people
Olivier at IGF, let me tell you it is not a joke.
Olivier I am always
I hate to be raising last call issues with my own document but such is
life.
1) Jim Schaad reports that our ASN.1 module is missing an import
statement.
2) Shortly after Jeff submitted the publication request, Tom Yu found
some problems with the assigned numbers in the IANA pre-authentication
Christian == Christian Vogt christian.v...@ericsson.com writes:
Christian Right. There is one limitation, though: With stateless
Christian NAT'ing alone, failover of active communication
Christian sessions between providers is not possible.
I agree with this statement.
Jari == Jari Arkko jari.ar...@piuha.net writes:
Jari Dave,
An accounting assessment of community views, justifying claims
of rough consensus, is the usual approach towards resolving
this kind of disparity.
Jari That sounds like a fine plan. We got most input during the
SM == SM s...@resistor.net writes:
SM Hi John,
SM At 18:09 13-10-2009, John C Klensin wrote:
This is the part of the review that I don't want to do unless
it is clear that it really belongs on Standards Track. If it
is an
SM I mentioned to the authors of this draft
I have reviewed the latest revisions of the update to rfc 3932 and
believe that would be a reasonable way forward. Thanks to the IESG
and authors for being responsive to the last call concerns.
--Sam
___
Ietf mailing list
Ietf@ietf.org
Olaf == Olaf Kolkman o...@nlnetlabs.nl writes:
Olaf On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:
Tim, I definitely agree with you that it should be the IETF community
that is last called. Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable
Robert == Robert Elz k...@munnari.oz.au writes:
Robert Then note that this is exactly the same ralationship that
Robert the RFC editor should have with the IETF.
I disagree for reasons I have previously stated.
___
Ietf mailing list
Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to do the
consensus call, that's fine with me. If we do that we'd need to make
it clear how this
Russ, I think that it is absolutely critical that the IETF be able to
attach a note to an RFC and that this note not simply be a
recommendation.
We can believe all we want that the IETF stream is just one stream and
that all other streams are independent. However, the RFC process is
very tightly
101 - 200 of 746 matches
Mail list logo
