Personal observation: "API" is a subclass of "interface". "Network
protocol" is a subclass of "interface". Interfaces (in the general
case) are valuable things to standardize. An abstract interface
("abstract API"?) that gives guidance to implementors above and beyond
the bare specification of t
The following information appeared on the pages I saw during the
course of reserving a room at the Marriott for IETF71. At least they
are admitting it plainly this time.
Renovation Information
Loud lobby and restaurant renovations will occur December 4,
2007-April 11, 2008 with work f
>>>>> "Tom" == Tom Yu <[EMAIL PROTECTED]> writes:
Tom> I might be able to locate a PDF copy of IEEE 1003.1 to verify
Tom> this claim. (I doubt I would want to obtain the physical bulk of
Tom> a dead-tree version of the document.)
I have looked at a copy
> "Frank" == Frank Ellermann <[EMAIL PROTECTED]> writes:
Frank> IMO an author should reference what (s)he's actually read,
Frank> guessing what an "official" (but commercial) document says
Frank> is risky.
What should be our standard of proof for determining whether a
standards document th
> "Brian" == Brian E Carpenter <[EMAIL PROTECTED]> writes:
Brian> On 2007-11-01 12:08, lconroy wrote:
>> Hi Tom, folks,
>> Many thanks for that. This is exactly what I wanted to know.
>> I understand that this is a distraction from the wider IPR crusade,
>> but I wonder if people should consid
> "lconroy" == lconroy <[EMAIL PROTECTED]> writes:
lconroy> Hi Folks,
lconroy> in the process of re-writing the ENUM Experiences draft, I wanted to
lconroy> check that its statement on the characters that can be found in POSIX
lconroy> Extended Regular Expressions (as called up in RFC 3402
> "Bob" == Bob Briscoe <[EMAIL PROTECTED]> writes:
Bob> Tom,
Bob> You're analysis of the impact on the ECN nonce is accurate. Below is
Bob> our reasoning for not including the ECN nonce capability in this
Bob> proposal...
[...]
Thanks for the detailed rationale of your decision to not includ
This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt.
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 editor
> "Ned" == Ned Freed <[EMAIL PROTECTED]> writes:
>> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
>> <[EMAIL PROTECTED]> wrote:
>> And it was a suggestion/ request that, before
>> this document was published in _any_ form, that it at least
>> acquire a clear discussion as to when o
> "pbaker" == Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:
pbaker> I agree that there were no technical comments but the summary
pbaker> states 'no comments'. Arguments on complexity are too easy to
pbaker> make. Every time a proposal is made I hear the complexity
pbaker> argument used a
10 matches
Mail list logo
