On 2009-12-04, at 07:38, Phillip Hallam-Baker wrote:
'largely semantic?'
Yes, by which I meant having little practical impact on the business of
shifting packets on the network. The other text that you couldn't see due to
the searing bright pain you apparently felt when presented with the
On Wed, Dec 02, 2009 at 02:12:01PM -0500, Phillip Hallam-Baker wrote:
The alternative would be to not use .local at all and insist on that
approach as a means of avoiding ICANNs perceived perogatives. I think
that would be a bad idea as the spec would not serve its intended
purpose.
I've been
The IESG has received a request from an individual submitter to
consider the following document:
'Extending ICMP for Interface and Next-hop Identification'
How droll. There was a presentation at the _2nd_ IETF (in Aberdeen, Maryland)
to add similar functionality (although in a less
Julian,
one detail of the recent change leading to draft-reschke-rfc2731bis-05
seems to be ill-advised -- and that is to be taken literally [*].
Whenever a new RFC Obsoletes a previous one, making a *Normative*
reference to the obsoleted RFC is nonsensical -- it effectively
produces a new
'largely semantic?'
Please do not ever use that phrase again as an attempt to dismiss the
importance of an argument
SEMANTICS IS MEANING
EVERY argument in the IETF is an argument in semantics, that is the
alpha and omega of the IETF process.
Arguments over semantics are only trivial when they
Hi Alfred,
I absolutely agree with you. I'll be happy to undo the change if the
IESG agrees.
Best regards, Julian
Alfred � wrote:
Julian,
one detail of the recent change leading to draft-reschke-rfc2731bis-05
seems to be ill-advised -- and that is to be taken literally [*].
Whenever a
On Thu, Dec 03, 2009 at 07:02:53PM +, Alexey Melnikov wrote:
Hi Nico,
Nicolas Williams wrote:
13.3. Additional Recommendations
If the application requires security layers then it MUST prefer the
SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS.
Spencer (minor): If prefer
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A (IP a): Local single Homed endpoint
Host_B (IP b(Primary), IP c(secondary)): Remote multiHomed endpoint
During Heartbeat I see that even though the Heart beat req is
I am supportive of updating *a* registry.
The OAuth working group has an open requirement for standard identifiers to
describe hash/digest functions.
What is not clear to me is the relationship of this registry and:
http://www.iana.org/assignments/hash-function-text-names/
which seems to
On Dec 4, 2009, at 12:57 PM, Sudhanva Mudigere Narayana Gowda wrote:
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A (IP a): Local single Homed endpoint
Host_B (IP b(Primary), IP c(secondary)): Remote
Hi,
you really want to be asking this on the TSVWG list. CC and Reply-To set
accordingly.
Lars
On 2009-12-4, at 1:57, Sudhanva Mudigere Narayana Gowda wrote:
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A
This raises the obvious question - shouldn't we take greater action than simply
update one of them? Should we consider combining them? Perhaps update the
reason why we have them and make them more useful for other use cases?
I am just looking for clarifications.
EHL
-Original
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'A Uniform Resource Identifier for Geographic Locations ('geo' URI) '
draft-ietf-geopriv-geo-uri-04.txt as a Proposed Standard
The IESG plans to make a decision in the next
The IESG has received a request from an individual submitter to consider
the following document:
- 'Extending ICMP for Interface and Next-hop Identification '
draft-atlas-icmp-unnumbered-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from an individual submitter to consider
the following document:
- 'The CERNET IVI Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition '
draft-xli-behave-ivi-05.txt as an Experimental RFC
The IESG plans to make a decision in the
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Hash Algorithms for HTTP Instance Digests '
draft-bryan-http-digest-algorithm-values-update-03.txt as an Informational
RFC
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from an individual submitter to consider
the following document:
- 'Definition of Master Key between PANA Client and Enforcement Point '
draft-ohba-pana-pemk-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework '
draft-ietf-ccamp-gmpls-ethernet-arch-07.txt as an
The Protocol for carrying Authentication for Network Access (pana) working
group in the Internet Area has concluded.
The IESG contact persons are Jari Arkko and Ralph Droms.
The mailing list will remain active.
This working group is closed after successfully completing its chartered
work. The
The IESG has received a request from an individual submitter to consider
the following document:
- 'Definition of a Uniform Resource Name (URN) Namespace for the Schema
for Academia (SCHAC) '
draft-giralt-schac-ns-02.txt as an Informational RFC
The IESG plans to make a decision in the
20 matches
Mail list logo
