Russ Housley wrote:
Pasi:
2) If this was published in a more academic environment, it would be
proper (and required) to cite related work, tracing the source of
ideas that were not entirely new. We don't usually have extensive
citations in RFCs, but in this context, perhaps it would be
approp
Pasi:
2) If this was published in a more academic environment, it would be
proper (and required) to cite related work, tracing the source of
ideas that were not entirely new. We don't usually have extensive
citations in RFCs, but in this context, perhaps it would be
appropriate to mention the pr
That is a reasonable change, and I will incorporate it during AUTH48.
Thanks!
-d
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 01, 2007 9:29 AM
> To: ietf@ietf.org; [EMAIL PROTECTED]
> Subject: Nit Re: Last Call:
> draft-wing-behave
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> This is of course one of the major motivations for
> draft-ietf-v6ops-nap-06.txt, which is now in the RFC Editor's
> queue. While it doesn't tell SOHO gateway vendors exactly
> what to do, it does I think make it clear that there is a
> se
Hi Bernard,
I received your review. I need more time to process given its length.
In fact the length of your review surprised me a bit given the long (>16
months) discussion we already had about the document.
Ciao
Hannes
> -Ursprüngliche Nachricht-
> Von: Bernard Aboba [mailto:[EMAIL P
Hi,
I have a nit on this otherwise highly useful draft as it goes to Last
Call.
I believe the reference to MGCP [RFC3435], sec 1 page 3, should be removed
and replaced by reference to Megaco / H.248 instead (RFC 3525 / 3015).
Correspondingly, the reference to it in section 8.2 should also be
This seems quite reasonable. If anything, it is about 10 years
overdue -- better late than never. :-)
Ran
On 1 Mar 2007, at 11:37, The IESG wrote:
The IESG has received a request from an individual submitter to
consider
the following document:
- 'CableLabs - IETF Standardization Collabora
> (2) NATs provide a huge advantage for customer support
> organizations of ISPs supporting such lower-end (in terms of
> financial returns, at least) connections. With a standardized
> NAT setup, the setups of all of their customers are pretty much
> the same, including the address ranges used by
Hi, Pasi,
On your second point - While the IETF is not a particularly academic
environment, it may also be appropriate to encourage the citation of prior
art that would move the marker for "inventions" back nearly 10 years... in a
place where we can find it in ten MORE years.
Thanks,
Spence
1) Given the situation, I would find Experimental a more appropriate
status for the document (and it seems that the required IANA
assignments can be obtained without being on standards track, so
probably no changed would be needed in the document).
2) If this was published in a more academic envi
Dear Thomas;
Please note that these are out of order, at least for the second entry.
Regards
Marshall
On Mar 2, 2007, at 8:13 AM, Thomas Narten wrote:
Total of 56 messages in the last 7 days.
script run at: Fri Mar 2 00:53:02 EST 2007
Messages | Bytes| Who
+-
Total of 56 messages in the last 7 days.
script run at: Fri Mar 2 00:53:02 EST 2007
Messages | Bytes| Who
+--++--+
16.07% |9 | 12.55% |41746 | [EMAIL PROTECTED]
1.79% |1 | 13.12% |43629 | [EMAIL PROTECTED
On 2007-03-01 18:57, John C Klensin wrote:
...
I continue to believe that, until and unless we come up with
models that can satisfy the underlying problems that NATs
address in the above two cases and implementations of those
models in mass-market hardware, NATs are here to stay, even if
we manag
13 matches
Mail list logo
