Subject: Re: [PCN] Fwd: New Version Notification for draft-karagiannis-pcn-signaling-requirements-01

From: ken carlberg <[email-masked]>
Date: Thu, 8 Jul 2010 15:03:07 -0400

Georgios,

I apologize for the very tardy comments on this draft, but I have a couple items that I'd like to bring up.  Also, I may have missed some emails, or earlier discussions, so please correct me where I missed something.

A general comment: I noticed in several (sub)sections that a fair amount of text describes things as they are.  This is fine and quite helpful in terms of context, but I would expect that at the most atomic level, there needs to be one of the traditional statements of "SHOULD, MAY, MUST", or their negative counterparts, somewhere in the text of that subsection.  For example, subsections 2.1, 2.2, 3.1, and 3.2 do not have any of the SHOULD/MAY/MUST verbage.  And if we take a more detailed look at 2.1, SHOULD the interval be between 100 to 500 ms, or is this a MUST?  I'm being a bit nit-picky here, but I think the document would be stronger with more precise language and positions in these subsection.

In version -00 of your document, you had section "2.3.7 Security" which was taken out of version -01 of your document.  Given that section 2.3.1 advocates placing a higher priority for signaling packets over data packets, I think you need to either reinsert 2.3.7, or significantly strengthen your Security Considerations section.  And along these lines, if priority is added in some form, then some corresponding form of message authentication & integrity should be applied.  And one can argue that this is a function of the form of prioritization.

-ken

On Mar 8, 2010, at 1:29 PM, Georgios Karagiannis wrote:

> Hi all
> 
> Based on the comments that we have received during the previous IETF
> meeting and email discussions we have updated the
> draft-karagiannis-pcn-signaling-requirements requirements draft, see:
> 
> http://www.ietf.org/id/draft-karagiannis-pcn-signaling-requirements-01.txt
> 
> If you have any comments please send them to us via the pcn mailing list!
> 
> Best regards,
> Georgios
> 
> 
> --- Original Message ---
> Date: 3/8/2010
> From: "IETF I-D Submission Tool" <[email-masked]>
> Subject: New Version Notification for
> draft-karagiannis-pcn-signaling-requirements-01
> 
> 
> 
> A new version of I-D, draft-karagiannis-pcn-signaling-requirements-01.txt
> has been successfuly submitted by Georgios Karagiannis and posted to the
> IETF repository.
> 
> Filename:	 draft-karagiannis-pcn-signaling-requirements
> Revision:	 01
> Title:		 Requirements for Signaling of (Pre-) Congestion Information in a
> DiffServ Domain
> Creation_date:	 2010-03-08
> WG ID:		 Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> Precongestion notification (PCN) is a means for protecting quality of
> service for inelastic traffic admitted to a Diffserv domain. The
> overall PCN architecture is described in RFC 5559. This memo
> describes the requirements for the signaling applied within the PCN
> domain: PCN feedback is carried from the PCN-egress-node to the
> decision point and the decision point may demand for the measurement
> and delivery of the PCN rate sent at the PCN-ingress-node. The
> decision point may be either collocated with the PCN-ingress-node or
> a centralized node.
> 
> 
> 
> The IETF Secretariat.
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 Jul 2010 10:48:30 +0200

Hi Ken

Thanks for your comments!

Please note that the newest version of the draft is the following, which is
a WG version:

http://www.ietf.org/id/draft-ietf-pcn-signaling-requirements-00.txt

Regarding the use of SHOULD and/or MUST we will need some discussions on the
mailing list on their use!

Best regards,
Georgios

> -----Original Message-----
> From: ken carlberg [mailto:[email-masked]] 
> Sent: donderdag 8 juli 2010 21:03
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [PCN] Fwd: New Version Notification for 
> I apologize for the very tardy comments on this draft, but I 
> have a couple items that I'd like to bring up.  Also, I may 
> have missed some emails, or earlier discussions, so please 
> correct me where I missed something.
> 
> A general comment: I noticed in several (sub)sections that a 
> fair amount of text describes things as they are.  This is 
> fine and quite helpful in terms of context, but I would 
> expect that at the most atomic level, there needs to be one 
> of the traditional statements of "SHOULD, MAY, MUST", or 
> their negative counterparts, somewhere in the text of that 
> subsection.  For example, subsections 2.1, 2.2, 3.1, and 3.2 
> do not have any of the SHOULD/MAY/MUST verbage.  And if we 
> take a more detailed look at 2.1, SHOULD the interval be 
> between 100 to 500 ms, or is this a MUST?  I'm being a bit 
> nit-picky here, but I think the document would be stronger 
> with more precise language and positions in these subsection.
> 
> In version -00 of your document, you had section "2.3.7 
> Security" which was taken out of version -01 of your 
> document.  Given that section 2.3.1 advocates placing a 
> higher priority for signaling packets over data packets, I 
> think you need to either reinsert 2.3.7, or significantly 
> strengthen your Security Considerations section.  And along 
> these lines, if priority is added in some form, then some 
> corresponding form of message authentication & integrity 
> should be applied.  And one can argue that this is a function 
> of the form of prioritization.
> 
> -ken
> 
> 
> 
> > A new version of I-D, 
> > draft-karagiannis-pcn-signaling-requirements-01.txt
> > has been successfuly submitted by Georgios Karagiannis and 
> posted to 
> > the IETF repository.
> > 
> > overall PCN architecture is described in RFC 5559. This 
> memo describes 
> > the requirements for the signaling applied within the PCN
> > decision point may be either collocated with the 
> PCN-ingress-node or a 
> > centralized node.
> > 
> > 
> > 
> > The IETF Secretariat.