Dearlove, Christopher (UK) wrote:
dcroc...@bbiw.net
From what you've written, your basic point seems to be that 51% isn't
enough; it's worth making that explicit.
To add to the confusion, and to emphasise the point about making clear,
British and American English differ here. If three
(off-list)
John C Klensin wrote:
The first sentence of the writeup template, As required by RFC
4858, this is the current template... is technically invalid
because RFC 4858, as an Informational document, cannot _require_
anything of the standards process.
I'm OK with asserting that an
Masataka Ohta wrote:
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the NSA, both of these are US
corporations), the whole system falls apart.
Right. PKI is
Doug Barton wrote:
Ted Lemon wrote:
M, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
If the problem is we don't know who's speaking, then fix that problem.
This doesn't work very well. [...] nobody likes getting yelled at.
I certainly don't like _having_ to yell.
Then come up with an
Ulrich Herberg wrote:
I think that the heat was exceptional. I have grown up in Munich, and
I have rarely ever seen it that hot (either in Munich or Berlin).
Maybe it's global warming? ;-)
Damn coincidences!
IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park,
and it was
Martin J. Dürst wrote:
On 2013/07/04 9:39, Barry Leiba wrote:
Registration for IETF87 in Berlin has been suspended to consider the impact
of a change in the VAT rules on Registration Fees. We expect registration
to open as soon as this matter has been clarified.
I don't understand what the
Martin Rex wrote:
Martin J. Dürst wrote:
On 2013/07/04 9:39, Barry Leiba wrote:
Registration for IETF87 in Berlin has been suspended to consider the
impact
of a change in the VAT rules on Registration Fees. We expect registration
to open as soon as this matter has been clarified
Dearlove, Christopher (UK) wrote:
I'd actually tried the authors, but no reply yet (only a few days).
I also tried the RFC Editor thinking they might have e.g. XML
from which extraction might have been easier, but also no response yet.
Extracting code from text is pretty trivial.
Use
Martin Rex wrote:
Dearlove, Christopher (UK) wrote:
I'd actually tried the authors, but no reply yet (only a few days).
I also tried the RFC Editor thinking they might have e.g. XML
from which extraction might have been easier, but also no response yet.
Extracting code from text
Phillip Hallam-Baker wrote:
RECOMMENDED is a strong suggestion that the implementation may override at
the discretion of the implementer. SHOULD is normative.
So the first tells me that I can make up my own mind, the second says that
I should give a reason if I don't comply.
This is only
Dave Crocker wrote:
And of course, the reality is that we allow bad specs out the door all
the time; we just allow fewer of them than many/most other standards
bodies...
But different to (at least some) other standards bodies, we lack an
official means to publish defect reports (aka
S Moonesamy wrote:
At 01:32 30-04-2013, Juergen Schoenwaelder wrote:
I am not sure what you think is unclear. Note that the definition of
the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
you can make a concrete text change proposal so I better understand
what your
Olaf Kolkman wrote:
Where things become difficult is at the point where the maintenance
of our standards need to be explained and questions about progression
on the standards ladder get asked.
Personally I hope that RFC 6410 has the effect that we, as a community,
get serious about
Brian E Carpenter wrote:
3. EME should have a very low or zero cost of entry for a content provider.
DRM system are evil in any way you look at it.
Originally, copyright was a conceived as a temporary (50yrs) monopoly.
The protection period has in recent years been prolonged in many years
to
Sam Hartman wrote:
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
Johannes Merkle wrote:
Limitations
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
This can be remedied by using an extension in which a server providing
white-list information conveys a hash of the
Brian E Carpenter wrote:
Seeing randomly selected drafts as a Gen-ART reviewer, I can
say that serious defects quite often survive WG review and
sometimes survive IETF Last Call review, so the final review
by the IESG does serve a purpose.
I'm currently seeing a document with some serious
Brian E Carpenter wrote:
I have no interest in or knowledge of the technical details,
but there is a pretty complicated DISCUSS against this draft,
which doesn't look like rubber-stamping to me:
https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/
I assume you've already let
SM wrote:
Ted Lemon wrote:
So in fact you don't need to put some percentage of white males on
the IESG, the IAB or the IAOC to make me happy. I want people on
these bodies who feel strongly about open standards, rough consensus
and running code. That's the kool-aid I have drunk,
Henry B. Hotz wrote:
Stefan Santesson ste...@aaa-sec.com wrote:
Nothing has changed in this regard.
The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that
Stefan Santesson wrote:
Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible
Stefan Santesson wrote:
It is risky to assume that existing clients would work appropriately
if you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
As I wrote: As long as the spec is
Sam Hartman wrote:
Martin Rex wrote:
Oh, here is a message from the Security AD back then (Sam
Hartman), commenting on requirements for rfc2560bis (the I-D
under last call right now!):
http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
To be clear, I didn't comment
Stefan Santesson wrote:
Unfortunately what you suggest would not be backwards compatible,
and can't be done within the present effort.
I'm sorry, I can not follow your arguments.
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8),
).
Should there be such broken clients, then you really do not want to use
them in the first place, because *EVERYONE* can feed those OCSP clients
arbitrary error codes in unsigned OCSPResponses.
-Martin
Martin Rex wrote:
Stefan Santesson wrote:
Unfortunately what you suggest would
Stefan Santesson wrote:
On 3/26/13 12:13 PM, Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly
Stefan Santesson wrote:
What OCSP client are you using that behaves like this?
On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote:
I would no longer get a popup from my OCSP client that tells my
that I'm unauthorized to submit OCSPRequests to that server, and that
the server has been moved
Stefan Santesson wrote:
I take it that the answer to my question is none.
Why would an rfc5019 client have a problem with a (7) instead of (6)
OCSPResponseStatus?
And what about an error code for only a single request that rfc5019
fails to specify.
Which is what I suspected. The semantics
Sam Hartman wrote:
Martin Rex m...@sap.com writes:
Martin http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
To be clear, I didn't comment on which error codes were overloaded to do
what. My point was simply that there needs to be a minimal set of
client behavior
).
-Martin
On 3/23/13 7:52 AM, Martin Rex m...@sap.com wrote:
The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol
The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP'
draft-ietf-pkix-rfc2560bis-15.txt as Proposed Standard
The
Melinda Shore wrote:
Martin Rex wrote:
As I understand and see it, the IESG is running IETF processes,
is mentoring IETF processes (towards WG Chairs, BOFs, individuals
with complaints/appeals), and is trying to keep an eye on the
overall architecture, and put togethe the pieces from
Melinda Shore wrote:
Stephen Farrell wrote:
FWIW, seems to me you're describing one leg of the elephant
each. From my experience I'd say you both actually have an
appreciation of the overall elephant but that's not coming
out in this kind of thread.
Since I personally participated only
Brian E Carpenter wrote:
Martin Rex wrote:
My impression of todays IESG role, in particular taking their
balloting rules and their actual balloting results into account,
is more of a confirming body of work that happened elsewhere
(primarily in the IETF, typically in IETF WGs
Keith Moore wrote:
Martin Rex wrote:
IMHO, the IESG is not (and maybe never was?) a committee where_each_
member reviews_all_ of the work, where_each_ forms his very own opionion,
and where all of them caste a VOTE at the end, so that the diversity
within that committee would
Margaret Wasserman wrote:
On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote:
I'd love to get out of this rat hole. Perhaps the signatories of the
open letter can restate the problem they see so it isn't made in terms of
race and gender.
The letter specifically
Jari Arkko wrote:
But I think we are missing a bit of the point in this discussion.
I do not feel that we need to prove we are somehow no worse than
industry average. The point is that *if* we had more diversity along
many of the discussed lines, we'd be far better off. For instance,
having
Melinda Shore wrote:
Martin Rex wrote:
While I agree that it helps avoiding a few big vendors bias.
is this really a significant problem _today_, adversely affecting a
non-marginal amount of the current IETF output, and in a fashion where
simply more diversity in the I* leadership would
Mikael Abrahamsson wrote:
I would just like to say I'm very grateful for the WGs that used Meetecho
to record their sessions. The HTML5 versions works out of the box with no
plugins in Chrome both on my Ubuntu 12.04 machine and Chrome on my
Windows7 machine. The sync of sound, slides,
Henrik Levkowetz wrote:
On 2013-02-27 10:20 Tim Chown said the following:
On 26 Feb 2013, at 20:28, Martin Rex m...@sap.com wrote:
I have a recurring remote participation problem with the
IETF Meeting Agendas, because it specifies the time of WG meeting slots
in local time (local
John Levine wrote:
[ Charset UTF-8 unsupported, converting... ]
There should be an immutable requirement that any alternative format
MUST NOT increase the size by more than a factor of two compared to
ASCII text.
So you're saying you're unalterably opposed to the RFC editor providing
PDF,
Bob Braden wrote:
On 3/4/2013 10:20 AM, Roger Jørgensen wrote:
I'll ask a rather basic question and hope someone will answer in an
educational way - Why is congestion control so important? And where
does it apply? ... :-)
Ouch. Because without it (as we learned the hard way in the
joel jaeggli wrote:
Michael Tuexen wrote:
Dale R. Worley wrote:
From: James Polk jmp...@cisco.com
Personally, I'd trust date -u much sooner than any random person.
Even better:
$ date --date='00:00 Feb 26, 2013 UTC'
Mon Feb 25 19:00:00 EST 2013
$
Requires a Unix
Jari Arkko wrote:
Agree with what John, Brian, and others have said. FWIW, at times
- particularly with documents having some controversy - the ADs are
left wondering what the silent majority is thinking.
I've previously mentioned that I believe the current IESG ballot rules
are insufficient.
Donald Eastlake wrote:
Let's see, here is the list of RFCs that the RFC Editor believes
update RFC 1035:
RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996,
RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2845,
RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC
Dave Cridland wrote:
On 10 Feb 2013 03:46, Dale R. Worley wor...@ariadne.com wrote:
In any case, if you are doing something incorrect in your review,
presumably people will call your attention to that fact, and explain
how you should change what you are doing and why you should change
Eliot Lear wrote:
On 1/25/13 4:27 PM, John C Klensin wrote:
a WG can skip WG LC if they think its not needed.
When was the last time that happened?
Did it require a consensus call to determine?
Chair discretion [... and five of paragraphs of text]
None of which answered my above
Stephen Farrell wrote:
On 01/25/2013 09:36 PM, Martin Rex wrote:
I don't know about the last time it happened, but I know about
one time in Nov-2009 in the TLS WG (now rfc5746).
I recall that and agree with the sequence of events you
describe, but I'm not sure that that situation
Dale R. Worley wrote:
From: Carsten Bormann c...@tzi.org
I think in protocol evolution (as well as computer system evolution
in general) we are missing triggers to get rid of vestigial
features.
That's quite true. Let us start by rationalizing the spelling and
punctuation of
John Leslie wrote:
I'm pretty darn uncomfortable _ever_ picking a fight with any
sitting AD, But I feel obligated to say this seems like a terrible
idea to me.
As a background, I'm a long-time believer in rough consensus for
Proposed Standard and running code for advancement along
SM wrote:
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Certificate Transparency'
draft-laurie-pki-sunlight-05.txt as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments
John Leslie wrote:
...
But more to the point, I think that in a lot of cases where
the IETF has done a good job, there has been running code
before the WG even started...
This perhaps explains where Stephen is coming from. Such
cases do exist; and it is arguable that the process
John Day wrote:
For any formal proofing system worth its dime, this can be 100% ruled out,
since the proofing system will emit a 100% bugfree implementation of the
spec in the programming language of your choice as a result/byproduct of the
formal proofing process.
C'mon. You don't really
John Day wrote:
It would be interesting to see you apply that.
This is what I have been talking about. The human mind's ability to
believe that the whole world sees everything the same way they do.
It really is quite amazing.
These so-called gaps often arise because they were unstated
John Day jeanj...@comcast.net wrote:
The reasons have been discussed or at least alluded to previously in this
thread. The short answer is we have been there and done that: 30 years ago.
All those tools were developed and used successfully in the 80s.
I know of cases where doing the
David Morris wrote:
John Levine wrote:
I agree with you that removing him would be the simplest approach, but I
can see possible situations where NOT following the process could lead
us into legal trouble.
Anyone can sue in the US for any reason, but this is silly.
The IAOC
Doug Barton wrote:
Andrew Sullivan wrote:
Let me get this straight: for the sake of procedures that are clearly
designed to be hard to use,
While I think that 3777 probably errs on the side of too hard to use,
recalling someone from one of these positions _should_ be hard to do,
and
Joe Touch wrote:
Lawrence Conroy wrote:
It is VERY useful to be able to search through drafts to see how we
got here, AND to see things that were explored and abandoned.
Thieves find it very useful to have what they steal. That doesn't
legitimize their theft.
Utility can determine
Joe Touch wrote:
There's nothing in the quote above that says that the expired document
will not be available *in the archive*.
There's nothing that says it won't be available by Santa Claus delivery
either. However, the document states how things will be made available,
and how that
Joe,
So it's not a slam dunk that you have the rights you think for every
I-D; you definitely don't have those rights for IDs
We're NOT talking about rights that were transfered from the document
author to arbitrary third parties here, but about rights that were
given to the IETF (IETF
Joe Touch wrote:
There were times when there were no rights granted explicitly, at least.
I indicated the three ranges in a previous mail.
In which case the Note Well concludently applies to the I-D contents,
which seems to have first appeared on www.ietf.org around 2001,
Barry Leiba wrote:
This raises the question of what expires means.
At the least, if IDs are published publicly forever, then expires is no
longer meaningful and the entirety of that notion needs to be expunged
from the ID process.
You seem to think it means something like expunged
Noel Chiappa wrote:
you want some level of privacy protection and therefore a fully dynamic
temporary DHCP-assigned IPv6 address
This turns out to be a chimera. Such addresses don't really provide any real
privacy - it turns out to be easy to track people through their access
Brian E Carpenter wrote:
[ Charset UTF-8 unsupported, converting... ]
On 06/08/2012 23:02, Martin Rex wrote:
Steven Bellovin wrote:
Randy Bush wrote:
whatever the number of address bits, if it is fixed, we always run out.
memory addressing has been a cliff many times. ip addressing
Mark Andrews wrote:
In message 5021742a.70...@dougbarton.us, Doug Barton writes:
On 08/07/2012 00:46, Martin Rex wrote:
IPv6 PA prefixes result in that awkward renumbering.
Avoiding the renumbering implies provider independent
network prefix.
ULA on the inside + https
Steven Bellovin wrote:
Randy Bush wrote:
whatever the number of address bits, if it is fixed, we always run out.
memory addressing has been a cliff many times. ip addressing. ...
Yup. To quote Fred Brooks on memory address space: Every successful
computer architecture eventually runs
Robert Raszuk wrote:
I understand that historically we had/still have SNMP however I have
never seen this being mandatory section of any standards track document.
Usually SNMP comes 5 years behind (if at all) making it obsolete by design.
NETCONF is great and very flexible communication
Randy Bush wrote:
Scott O Bradner wrote:
2804 does not say not to talk about such things - or that such
documents should not be published as RFCs - 2804 says that the
IETF will not do standards work in this area
for those of us who are easily confused, could you differentiate between
John Levine wrote:
[ Charset UTF-8 unsupported, converting... ]
You're not going to find cool temperatures again in July or August
unless you go as far south as Argentina or New Zealand.
Not only is there life north of the 60th parallel (N), there are
even hotels and restaurants and
Russ Housley wrote:
Brian:
There was no announcement that this change was about to be deployed;
however, there was a long discussion of the change. It started with
a request for the HTML version of the I-D instead of the plain
text version. At the end of the discussion the decision was to
Abdussalam Baryun wrote:
For example, in one of the WG discussion on list, two members of WG
have referenced a history-discussion and informed me to read them
regarding some subject, I did do that but was *lost in translation*. I
now think that the memebrs' advise was to a wrong direction.
Peter Saint-Andre wrote:
So the way we introduce some people to the IETF is to expect that they
will look up fifty unfamiliar words and phrases? Having taught English
as a second language, I can attest that some of the idioms and
colloquialisms included in this document would have caused
Stephen Farrell wrote:
I'm with Brian and Yoav on this. I don't see a need
to change here. And I do think we might lose something
if we become too PC. If a bunch of non-native speakers
did say yes, I found that made the document less
useful then I'd be more convinced that all these
changes
Peter Sylvester wrote:
On 05/10/2012 11:17 AM, David Morris wrote:
I object to the quantum change in ease of access and persistence of the
information. I see way too much aggregation of personal information and
don't think open-ness is justification for increasing that potential.
+1
Russ Housley wrote:
BCP 79 says:
Reasonably and personally known: means something an individual
knows personally or, because of the job the individual holds,
would reasonably be expected to know. This wording is used to
indicate that an organization cannot
Melinda Shore wrote:
On 5/10/12 5:04 AM, Martin Rex wrote:
Peter Sylvester wrote:
On 05/10/2012 11:17 AM, David Morris wrote:
I object to the quantum change in ease of access and persistence of the
information. I see way too much aggregation of personal information and
don't think
John C Klensin wrote:
I hate the idea of the community getting embroiled in accusations and
counter-accusations but one advantage to a working IPR policy
(as well as general openness) of publishing the blue sheets is
the ability to notice and send reminder notes of the form of
hey, I think
Warren Kumari wrote:
-- if you are active in the IETF (or even if you aren't), you email
address is already known to the spammers. Our lists, and list archives
are all public
If the blue sheets would _only_ contain PII that is _already_available_
in other places, then we should stop
Hannes Tschofenig wrote:
When people suggest new work to the IETF they often see a strange
reaction. I remember when Mozilla came to the IETF and proposed to
work on the privacy topic Do Not Track. I couldn't find support
for doing the work in the IETF. I don't exactly know why people
Is it really so completely out of this world to expect the decency
to ask whether it is OK to take a photo for the purpose of _publication_?
Leaving it up to the individual subjects whether they prefer to
relocate further to the background first or prefer to temporarily
leave the room? Especially
John C Klensin wrote:
I will accept your interpretation as stated but, if that
interpretation is correct, I believe the IETF should not meet
there while those provisions are in effect unless at least one
of the following conditions arises:
The overview that Michael StJohns (thanks!) pointed
John C Klensin wrote:
Martin Rex m...@sap.com wrote:
Identifying contributors or participants and publishing persons
photos or portaits are two very distinct things, and the former
does not require the latter at all.
In principle, I could keep the pictures to myself and put a list
Tony Finch wrote:
Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where should we
be looking?
The only thing I have found that implies NOTIMP doesn't apply to
Martin Rex wrote:
Tony Finch wrote:
Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where should we
be looking?
The only thing I have found
The id-announce mails are defective.
I thought the proposal was to ADD a URL to the HTML/tools or
datatracker versions of the I-D, rather than remove the URL
to the versioned TXT file.
While Barry Leibas suggested Greasemonkey script curiously fixes the
404 error created by the recent change to
Mark Andrews wrote:
Martin Rex writes:
Thanks for mentioning rfc 4074. The stuff in that document matches
the thoroughly broken behaviour of the IPv6 DNS resolver client of
Windows 2003 that I had encountered just recently.
IMO, rfc4074 exhibits a significant amount
Martin Rex wrote:
So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor,
what you're left with might be ureflecteduntested guessing
on part
Sorry,
s/some 3-4 conditions/some 3-4 dozen conditions/
Martin Rex wrote:
Martin Rex wrote:
So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor
Mark Andrews wrote:
The incredibly huge base that returned NOERROR to type 28 queries
when was defined. Almost all of the offending boxes were
designed after was defined.
When was defined is marginally relevant. Since IPv6 was designed
as a completely seperate universe, it
Mark Andrews wrote:
not permitted would require a must not, but
I only see a should not here:
http://tools.ietf.org/html/rfc1035#section-5.2
RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc.
5.2. Use of master files to define zones
When a master file is used to
Mark Andrews wrote:
Martin Rex writes:
Mark Andrews wrote:
John Levine writes:
In case it wasn't clear, this is an authoritative server.
If this is about permitted RCODEs here
http://tools.ietf.org/html/rfc1035#section-4.1.1
then an RCODE of 4 in the response
Mark Andrews wrote:
Randy claimed that presentation formats were not standardised. They
are. Randy and others claimed that the presentation formats were
owned by BIND and they are not.
I never claimed that STD 13 was the be all and end all w.r.t. DNS.
STD 13 didn't follow the normal
Mark Andrews wrote:
John Levine writes:
In case it wasn't clear, this is an authoritative server.
If this is about permitted RCODEs here
http://tools.ietf.org/html/rfc1035#section-4.1.1
then an RCODE of 4 in the response looks like a perfectly valid response
for a DNS Server to a
Bob Hinden wrote:
Martin Rex wrote:
With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.
Right, just like they could have deployed dual stack many years ago too.
Just two days
Mark Andrews wrote:
ned+i...@mauve.mrochek.com writes:
Which brings us right back to my original point: This definition of
ready is operationally meaningless in many cases.
Correct.
I contend that OS are IPv6 ready to exactly the same extent as they
are IPv4 ready. This isn't a
Murray S. Kucherawy wrote:
From: Richard Barnes [mailto:rbar...@bbn.com]
Seems like it depends on your definitions of abusive and
legitimate. Do you have an example?
For a contrived example, let's say a registered HTTP header field
that's only ever found to be present in web pages
Robert Hernady wrote:
I'm looking for the better understanding for the
RFC 2560 Online Certificate Status Protocol - OCSP.
The section 4.1 defines the ASN.1 structure for the OCSP request.
Follows the shortened structure.
OCSPRequest
TBSRequest
OPTIONAL Signature,
where the
Bob Braden wrote:
Within the ARPA-funded Internet research program that designed IP and
TCP, Jon Postel and Danny Cohen argued strenuously for variable length
addresses. (This must have been around 1979. I cannot name most of the
other 10 people in the room, but I have a clear mental
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually
Pete Resnick wrote:
Do you, or do you not, object to the proposed change that changes the
text from saying, This space may be used just as 1918 space to This
space has limitations and cannot be used as 1918 space? Nobody on the
list objected to that new text. That new text significantly
1 - 100 of 332 matches
Mail list logo
