Re: Last Call: draft-ietf-tsvwg-port-randomization (Transport Protocol Port Randomization Recommendations) to BCP

[SM]

At 07:01 16-02-10, you wrote:

The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:

- 'Transport Protocol Port Randomization Recommendations '
as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the


In Section 3.2:

  "Since this range includes ports numbers assigned by IANA, this may
   not always be possible, though.  A possible workaround for this
   potential problem would be to maintain a local list of the port
   numbers that should not be allocated as ephemeral ports.  Thus,
   before allocating a port number, the ephemeral port selection
   function would check this list, avoiding the allocation of ports that
   may be needed for specific applications."

Is that the list of ports in the ephemeral port range assigned by 
IANA or the list of ports that may be needed by specific applications 
on the host?


In Section 3.3:

  "Transport protocols SHOULD obfuscate the allocation of their
   ephemeral ports, since this help to mitigate a number of attacks that
   depend on the attacker's ability to guess or know the five-tuple that
   identifies the transport protocol instance to be attacked."

The title of Section 3.3 says Obfuscation while the algorithms in the 
sub-sections are called "randomization".


With respect to the love note in this draft, I have reason to believe 
any decision in that area only requires the consensus of the two 
parties. I wish Fernando Gont good luck. :-)


Regards,
-sm

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)

[James M. Polk]

At 11:04 PM 3/2/2010, Fernando Gont wrote:

(added CC to tsvwg)

Hello, Alfred,

Thanks so much for your feedback! Comments inline


> (1)  Fundamental, general issue: Terminology
>
> A few voices have caused the authors to adopt a rather questionable
> terminology throughout the draft, during its last few revisions.
>
> - "Randomization" : My 5-vol. Dictionary of Mathematics defines
>(translated into English):  Randomization; Randomized Algorithm:
>The introduction of randomness into mathematical algorithms.
>In practice, pseudo-random numbers are used.
[]
>
> I therefore request that these inappropriate changes in terminology be
> backed out again.  "Port number obfuscation" is a serious misnomer;
> port numbers still are transmitted in the clear under the methods
> presented in this draft; so "port number randomization" or, for short,
> "port randomization" is the proper term -- and it is widely adopted
> by the community since several years.

I really don't know how to proceed here. That is, I'd honor your
comment, but clearly that's not just up to me. What do the chairs and
ADs think?


Fernando and Alfred

"randomization" in computing -- at least to me -- requires or 
necessitates a randomizer (pseudo or not), which this document 
doesn't attempt to specify or produce, so I'll have a hard time 
getting by this recommendation of yours.


FWIW -- this was a specific point of discussion within the TSVWG, and 
not just a passing comment. We discussed this at length during a 
meeting, and in email with the ADs involved.


My co-chair ought to chime in here if he feels strongly one way or the other.

James




> (2)  Abstract, last sentence
>
> The new elaborations on RTP seem to be inappropriate.
> RTP isn't a "classical" transport protocol.
> RFC 3550 says (Section 11, 2nd para):
>
>  "RTP relies on the underlying protocol(s) to provide demultiplexing of
>   RTP data and RTCP control streams.  For UDP and similar protocols, ..."
[...]
>
> Therefore, I suggest to drop the clause on RTP entirely:

FWIW, Dan Wing suggested this as one of the possible ways forward for
the RTP issue. So unless anybody disagrees I will apply your prosed change.


> (3)  Abstract and Section 1 (1st para)
>
>   "Recently, awareness has been raised ..."
>
> The same words had been written in the first draft version in 2006.
> For not overstressing the word "recent" too much, I suggest to change
> that to:
>
>   "During the last few years, awareness has been raised ..."
>^

Fixed.


>
> (4)  Section 2.1
>
> There is ongoing confusion on the role of the IANA managed port number
> range.  This is caused by the lack of distinguishing between the roles
> of ports -- server ports ((semi-)static port numbers used to 'listen')
> vs. client ports (ephemeral choice for activating a transport session
> with a 'listening' peer).  In certain 'symmetric' protocols (peer-to-
> peer applications) without out-of-band agreement on port numbers,
> both communicating parties are to be regarded as taking the 'server'
> role, and for these the document is not applicable.
> To avoid the above confusion, I strongly suggest to clarify that the
> IANA registry *only* deals with *server port numbers*.
>
> First paragraph of 2.1:
>
>The Internet Assigned Numbers Authority (IANA) assigns the unique
>parameters and values used in protocols developed by the Internet
> |  Engineering Task Force (IETF), including well-known ports [IANA].
>[...]
> ---
>The Internet Assigned Numbers Authority (IANA) assigns the unique
>parameters and values used in protocols developed by the Internet
> |  Engineering Task Force (IETF), including well-known server ports
>[IANA].  [...]
>^^
> With this clarification, it should become evident that the use of
> arbitrary port numbers as ephemeral port numbers on a particular node
> does not conflict with the IANA registry, unless the same port number
> is in use by a (listening) server application on the same node.

Ok. Given that the port numbers issue has been debated recently, I'd
like Lars to comment on this proposed change.



> The last paragraph of 2.1 is not backed by RFC 1122 (cf. sect. 4.2.2.1).
> Wrt the IANA Port number registry, Dynamic / Private Ports are simply
> those ports that are recommended for *server* programs that want to
> dynamically bind to a port they are listening on afterwards.
> Neither the TCP standard nor STD 3 contains verbiage to globally
> constrain port usage as ephemeral (client) ports.
>
> Therefore, IMO the last paragraph of 2.1 should be deleted or changed
> as follows:
>
>The dynamic port range defined by IANA consists of the 49152-65535
> |  range, and is meant for the selection of ephemeral ports.
> ---
>The dynamic port range defined by IANA consists of the 49152-65535
> |  range; it is meant for the dynamic selection of server ports and is

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)

[Fernando Gont]

(added CC to tsvwg)

Hello, Alfred,

Thanks so much for your feedback! Comments inline


> (1)  Fundamental, general issue: Terminology
> 
> A few voices have caused the authors to adopt a rather questionable
> terminology throughout the draft, during its last few revisions.
> 
> - "Randomization" : My 5-vol. Dictionary of Mathematics defines
>(translated into English):  Randomization; Randomized Algorithm:
>The introduction of randomness into mathematical algorithms.
>In practice, pseudo-random numbers are used.
[]
> 
> I therefore request that these inappropriate changes in terminology be
> backed out again.  "Port number obfuscation" is a serious misnomer;
> port numbers still are transmitted in the clear under the methods
> presented in this draft; so "port number randomization" or, for short,
> "port randomization" is the proper term -- and it is widely adopted
> by the community since several years.

I really don't know how to proceed here. That is, I'd honor your
comment, but clearly that's not just up to me. What do the chairs and
ADs think?



> (2)  Abstract, last sentence
> 
> The new elaborations on RTP seem to be inappropriate.
> RTP isn't a "classical" transport protocol.
> RFC 3550 says (Section 11, 2nd para):
> 
>  "RTP relies on the underlying protocol(s) to provide demultiplexing of
>   RTP data and RTCP control streams.  For UDP and similar protocols, ..."
[...]
> 
> Therefore, I suggest to drop the clause on RTP entirely:

FWIW, Dan Wing suggested this as one of the possible ways forward for
the RTP issue. So unless anybody disagrees I will apply your prosed change.


> (3)  Abstract and Section 1 (1st para)
> 
>   "Recently, awareness has been raised ..."
>
> The same words had been written in the first draft version in 2006.
> For not overstressing the word "recent" too much, I suggest to change
> that to:
> 
>   "During the last few years, awareness has been raised ..."
>^

Fixed.


> 
> (4)  Section 2.1
> 
> There is ongoing confusion on the role of the IANA managed port number
> range.  This is caused by the lack of distinguishing between the roles
> of ports -- server ports ((semi-)static port numbers used to 'listen')
> vs. client ports (ephemeral choice for activating a transport session
> with a 'listening' peer).  In certain 'symmetric' protocols (peer-to-
> peer applications) without out-of-band agreement on port numbers,
> both communicating parties are to be regarded as taking the 'server'
> role, and for these the document is not applicable.
> To avoid the above confusion, I strongly suggest to clarify that the
> IANA registry *only* deals with *server port numbers*.
> 
> First paragraph of 2.1:
> 
>The Internet Assigned Numbers Authority (IANA) assigns the unique
>parameters and values used in protocols developed by the Internet
> |  Engineering Task Force (IETF), including well-known ports [IANA].
>[...]
> ---
>The Internet Assigned Numbers Authority (IANA) assigns the unique
>parameters and values used in protocols developed by the Internet
> |  Engineering Task Force (IETF), including well-known server ports
>[IANA].  [...]
>^^
> With this clarification, it should become evident that the use of
> arbitrary port numbers as ephemeral port numbers on a particular node
> does not conflict with the IANA registry, unless the same port number
> is in use by a (listening) server application on the same node.

Ok. Given that the port numbers issue has been debated recently, I'd
like Lars to comment on this proposed change.



> The last paragraph of 2.1 is not backed by RFC 1122 (cf. sect. 4.2.2.1).
> Wrt the IANA Port number registry, Dynamic / Private Ports are simply
> those ports that are recommended for *server* programs that want to
> dynamically bind to a port they are listening on afterwards.
> Neither the TCP standard nor STD 3 contains verbiage to globally
> constrain port usage as ephemeral (client) ports.
> 
> Therefore, IMO the last paragraph of 2.1 should be deleted or changed
> as follows:
> 
>The dynamic port range defined by IANA consists of the 49152-65535
> |  range, and is meant for the selection of ephemeral ports.
> ---
>The dynamic port range defined by IANA consists of the 49152-65535
> |  range; it is meant for the dynamic selection of server ports and is
> |  unrelated to ephemeral port selection, although this interpretation
> |  has been promoted in the past.

Your suggested change makes sense to me. But as with the previous one,
I'd like to hear what Lars thinks about this one.



> (5)  General
> 
> A few editorial nits will be reported to the authors off-list ASAP.

Looking forward to them!

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




___
Ietf

Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC

[Georgios Karagiannis]

Hi Jerry

We will include in the Appendix a similar example as the one given in
Section 3.4 of the QSPEC draft.

Best regards,
Georgios

On 3/2/2010, "Gerald Ash"  wrote:

>One more comment:
> 
>Section 3.1 of the QSPEC draft 
>http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.1 lists 
>requirements for QOSM specifications including "QNE processing rules 
>describing how QSPEC information is treated and interpreted"and "at least one 
>bit-level QSPEC example".
> 
>While the RMD draft has examples in Appendix A of individual processing 
>functions, there is no overall, end-to-end example given of QSPEC composition 
>and processing from QNI to QNR and back again.  IMO this would greatly help an 
>overall understanding of RMD functionality.
> 
>Such QSPEC processing examples are given in Sections 4.4 ("Processing 
>Example") and 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft 
>(http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.4)
>and
>Section 3.4 ("Example of QSPEC Processing") of the QSPEC draft 
>(http://toolsietf.org/html/draft-ietf-nsis-qspec-24#section-3.4).
> 
>Thanks,
>Jerry
>
>--- On Mon, 3/1/10, Gerald Ash  wrote:
>
>
>From: Gerald Ash 
>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource 
>Management in Diffserv QOS Model) to Experimental RFC
>To: ietf@ietf.org, n...@ietf.org
>Cc: "Jerry Ash" 
>Date: Monday, March 1, 2010, 2:20 PM
>
>
>
>
>
>
>
>Minor editorial comments:
> 
>1. page 35:
>"  the "Peak Data Rate-1 (p)" value of the  parameter.
>   When the QNE edges use aggregated intra-domain QoS-NSLP operational
>   states, then the "Peak Data Rate-1 (p)" value of the "
>substitute  for  
> 
>2. page 101:
>"  directions by using the procedure described in Section 4.6.2.3 and
>   including in the   parameter within the "RMD-QOSM QOS
>   Description" field carried by the "forward" intra-domain RESERVE the"
>substitute  for 
> 
>Thanks,
>Jerry
>
>
>--- On Mon, 3/1/10, The IESG  wrote:
>
>
>From: The IESG 
>Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource 
>Management in Diffserv QOS Model) to Experimental RFC
>To: "IETF-Announce" 
>Cc: n...@ietf.org
>Date: Monday, March 1, 2010, 9:38 AM
>
>
>The IESG has received a request from the Next Steps in Signaling WG 
>(nsis) to consider the following document:
>
>- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
>    as an Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>ietf@ietf.org mailing lists by 2010-03-22. Exceptionally, 
>comments may be sent to i...@ietf.org instead. In either case, please 
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12558&rfc_flag=0
>
>___
>nsis mailing list
>n...@ietf.org
>https://www.ietf.org/mailman/listinfo/nsis
>
>
>
>
>  )
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC

[Gerald Ash]

One more comment:
 
Section 3.1 of the QSPEC draft 
http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.1 lists 
requirements for QOSM specifications including "QNE processing rules describing 
how QSPEC information is treated and interpreted"and "at least one bit-level 
QSPEC example".
 
While the RMD draft has examples in Appendix A of individual processing 
functions, there is no overall, end-to-end example given of QSPEC composition 
and processing from QNI to QNR and back again.  IMO this would greatly help an 
overall understanding of RMD functionality.
 
Such QSPEC processing examples are given in Sections 4.4 ("Processing Example") 
and 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft 
(http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.4)
and
Section 3.4 ("Example of QSPEC Processing") of the QSPEC draft 
(http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.4).
 
Thanks,
Jerry

--- On Mon, 3/1/10, Gerald Ash  wrote:


From: Gerald Ash 
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource 
Management in Diffserv QOS Model) to Experimental RFC
To: ietf@ietf.org, n...@ietf.org
Cc: "Jerry Ash" 
Date: Monday, March 1, 2010, 2:20 PM







Minor editorial comments:
 
1. page 35:
"  the "Peak Data Rate-1 (p)" value of the  parameter.
   When the QNE edges use aggregated intra-domain QoS-NSLP operational
   states, then the "Peak Data Rate-1 (p)" value of the "
substitute  for  
 
2. page 101:
"  directions by using the procedure described in Section 4.6.2.3 and
   including in the   parameter within the "RMD-QOSM QOS
   Description" field carried by the "forward" intra-domain RESERVE the"
substitute  for 
 
Thanks,
Jerry


--- On Mon, 3/1/10, The IESG  wrote:


From: The IESG 
Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource 
Management in Diffserv QOS Model) to Experimental RFC
To: "IETF-Announce" 
Cc: n...@ietf.org
Date: Monday, March 1, 2010, 9:38 AM


The IESG has received a request from the Next Steps in Signaling WG 
(nsis) to consider the following document:

- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
    as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-22. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12558&rfc_flag=0

___
nsis mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nsis




  ___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

[Masataka Ohta]

Shumon Huque wrote:

> "EV" = Extended Validation certificates.

Extending human validation is still human.

> Re-establishing (Establishing?) the concept of accountability, 

No, thanks.

For accountability with regard to full compensation for losses, that
is, *M*O*N*E*Y*, CAs are not accountable at all.

That's all.


Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: ietf 1id_guidelines tool broken

[William Allen Simpson]

Many thanks to Stephanie for manually overriding the broken tool(s), and
processing the draft this morning.

After 3 dozen RFCs over 22+ years, that was my first attempt to use the
automated submission tool -- a mistake I'm unlikely to make again


William Allen Simpson wrote:

The URL provided by the secretariat in an email on Feb 25th was:

I-D Submission Tool URL: 
https://datatracker.ietf.org/idst/status.cgi?submission_id=21622


At this moment in time today, that still doesn't work:


Your request was not processed due to the following error(s):
Error - Draft is not in an appropriate status for the requested page



Even though the draft has already been posted this morning, this status
tool still doesn't work.  The same quality of work as the idnits tool.

Hopefully, the putative author can devote some attention to translating
that meaningless drivel into something more user friendly.  Perhaps after a
refresher course on ego-less programming -- and professional counseling for
anger management
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

[Shumon Huque]

On Tue, Mar 02, 2010 at 06:13:28AM +0900, Masataka Ohta wrote:
> Phillip Hallam-Baker wrote:
> 
> > Moving to DNSSEC, regardless of the technical model does not eliminate
> > the need for certificates or CAs. The purpose of EV certificates is to
> > re-establish the principle of accountability.
> 
> I don't know what EV means, but anything human, including CA, is not
> infallible, which is why PKI is insecure.

"EV" = Extended Validation certificates.

Re-establishing (Establishing?) the concept of accountability, I think, 
requires more than introduction of EV certificates. Assuming that there 
is even agreement that they have a more accountable CPS, it also requires
removal of the allegedly non-accountable CAs from trust anchor lists.
This hasn't happened.

There is also the question of the actual effectiveness of EV
certificates. Do they really work? Can their indicators be spoofed?
And can normal users use their visual cues to actually make informed 
security decisions? There appears to be a growing body of empirical
work that shows that the typical user is unable to make effective 
security decisions based on certificates and their complex set of 
indicators (whether they are EV branded or not).

Here are a few pointers, which I'm sure many folks on this list are
well aware of ..

* An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks
  ISSN0302-9743 (Print) 1611-3349 (Online)
  Financial Cryptography and Data Security, 2007
  http://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf

* Why Phishing Works
  http://people.seas.harvard.edu/~rachna/papers/why_phishing_works.pdf
  2006

* The Emperor's New Security Indicators: An evaluation of website
  authentication and the effect of role playing on usability studies.
  http://www.usablesecurity.org/emperor/
  May 2007

* Crying Wolf: An Empirical Study of SSL Warning Effectiveness
  http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf
  July 2009

And the paper I know of that supports the effectiveness of EV:

* Extended Validation SSL: Green Address Bar Consumer Research
  Verisign/Thawte/Tec-Ed study:
  http://www.verisign.com.sg/guide/ssl-ev/EV-SSL-GreenBarResearch.pdf

There have been extensive discussions on this topic on various other
lists (cryptography, w3c, etc), and I'm not sure I look forward to
seeing all of it rehashed on the IETF list. But I would be interested
in pointers to other credible studies on this topic.

--Shumon.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Patent disclosure in draft-shin-augmented-pake-00.txt

[SeongHan Shin]

Dear Simon,

Thank you for your interests and a kind suggestion.
I am now contacting with our institute Intellectual Property Department 
about the license information.

With the response from IP department, I want to get your feedback or advices

about license information (if you don't mind).

Have a nice day!
Best regards,
Shin


> -Original Message-
> From: Simon Josefsson [mailto:si...@josefsson.org]
> Sent: Tuesday, March 02, 2010 6:53 AM
> To: seonghan.s...@aist.go.jp
> Cc: ietf@ietf.org
> Subject: Patent disclosure in draft-shin-augmented-pake-00.txt
> 
> Hi.  This document [1] contains the following section:
> 
> 6.  Intellectual Property
> 
>The National Institute of Advanced Industrial Science and Technology
>(AIST) has submitted a patent application about the AugPAKE protocol,
>described in this document.  For details of the patent application
>and its status, please contact the authors of this document.
> 
> That by itself does not fulfill the IETF procedures regarding patent
> disclosure.  Please read section 6.1 of RFC 3979:
> 
> http://tools.ietf.org/html/rfc3979#section-6.1
> 
> Searching for a patent disclosure on this document suggests that none
> has been filed (yet):
> 
> https://datatracker.ietf.org/ipr/search/?option=document_search&docume
> nt_search=draft-shin-augmented-pake
> 
> Therefor you need to file the proper patent disclosure for your
> submission to comply with the IETF rules.
> 
> To make your technology benefit Internet applications everywhere, please
> consider licensing your patent in a liberal way.  One example what I
> believe is a friendly patent license would be this one:
> 
> https://datatracker.ietf.org/ipr/941/
> 
> Writing a patent license in friendly way is complicated, if you are
> interested I can work with you and the Free Software Foundation or the
> Software Freedom Law Center to help you write a good license.
> 
> Thanks,
> /Simon
> 
> [1]
> http://www.ietf.org/internet-drafts/draft-shin-augmented-pake-00.txt


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The ResourceManagement in Diffserv QOS Model) to Experimental RFC

[Georgios Karagiannis]

Hi Jerry
 
Thank you very much for the catch!
 
We will update the draft accordingly!
 
Best regards,
Georgios
 


  _  

From: nsis-boun...@ietf.org [mailto:nsis-boun...@ietf.org] On Behalf Of
Gerald Ash
Sent: maandag 1 maart 2010 20:20
To: ietf@ietf.org; n...@ietf.org
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The
ResourceManagement in Diffserv QOS Model) to Experimental RFC



Minor editorial comments:
 
1. page 35:
"  the "Peak Data Rate-1 (p)" value of the  parameter.
   When the QNE edges use aggregated intra-domain QoS-NSLP operational
   states, then the "Peak Data Rate-1 (p)" value of the "
substitute  for  
 
2. page 101:
"  directions by using the procedure described in Section 4.6.2.3 <>  and
   including in the   parameter within the "RMD-QOSM QOS
   Description" field carried by the "forward" intra-domain RESERVE the"
substitute  for 
 
Thanks,
Jerry


--- On Mon, 3/1/10, The IESG  wrote:



From: The IESG 
Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource
Management in Diffserv QOS Model) to Experimental RFC
To: "IETF-Announce" 
Cc: n...@ietf.org
Date: Monday, March 1, 2010, 9:38 AM


The IESG has received a request from the Next Steps in Signaling WG 
(nsis) to consider the following document:

- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org 
mailing lists by 2010-03-22. Exceptionally, 
comments may be sent to i...@ietf.org
  instead. In
either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id
 &dTag=12558&rfc_flag=0

___
nsis mailing list
n...@ietf.org  
https://www.ietf.org/mailman/listinfo/nsis



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)

[Phillip Hallam-baker]

Grid is a specific term that describes a community of use as well as a  
technology


The cloud is a marketting term that means 'magic happens here' and I  
mean that without insulting intent it is a foggy sort of concept,  
litterally,and there I mean litterally litterally



Grid is a style of loosely coupled mimd computing. A grid worth the  
name can distribute a task across hundreds of nodes it is general  
purpose parallel processing


Cloud computing is outsourced services. That could be general purpose  
as in amazon elastic compute cloud or could be very speciffic like  
gmail or twitted



Sent from my iPhone

On Feb 22, 2010, at 1:08 PM, Dave CROCKER  wrote:




On 2/22/2010 12:59 PM, Melinda Shore wrote:

On Feb 22, 2010, at 11:52 AM, Brian E Carpenter wrote:
My thought exactly. The distinction between cloud computing and  
open grid

computing is very small (or possibly zero)


With all due respect, Brian, it's really not. With cloud
computing you're typically dealing with multitenanting issues
and a bunch of other layer 8-9 stuff that tends (of necessity)
to be reflected down the stack, and I think I can see an
argument for cloud computing belonging in the RAI space,
or at least having substantial overlap.



Having recently gone through the exercise of trying to understand  
what these different terms actually meant, I discovered that the  
underlying problem is that you are both right, as are a variety of  
other people who have other views...


As already noted, the term 'cloud' is now used in many different  
ways, including as a synonym for 'network' and for 'Internet', even  
amongst technical folk. (Really.)


There are some people who have very specific and nuanced technical  
definitions, including distinguishing cloud from grid.  But no set  
of definitions seems to have a broad base of support.


For defining 'cloud', one group I'm participating in decided it was  
happy with the NIST language:


  

d/

--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC

[Gerald Ash]

Minor editorial comments:
 
1. page 35:
"  the "Peak Data Rate-1 (p)" value of the  parameter.
   When the QNE edges use aggregated intra-domain QoS-NSLP operational
   states, then the "Peak Data Rate-1 (p)" value of the "
substitute  for  
 
2. page 101:
"  directions by using the procedure described in Section 4.6.2.3 and
   including in the   parameter within the "RMD-QOSM QOS
   Description" field carried by the "forward" intra-domain RESERVE the"
substitute  for 
 
Thanks,
Jerry


--- On Mon, 3/1/10, The IESG  wrote:


From: The IESG 
Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource 
Management in Diffserv QOS Model) to Experimental RFC
To: "IETF-Announce" 
Cc: n...@ietf.org
Date: Monday, March 1, 2010, 9:38 AM


The IESG has received a request from the Next Steps in Signaling WG 
(nsis) to consider the following document:

- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
    as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-22. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12558&rfc_flag=0

___
nsis mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nsis



  ___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf