Subject: [tsvwg] End of WGLC: WG Chair comments for RSVP Extensions for Admission Priority

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 07 Nov 2009 11:35:40 +0000

Sorry for the delay. This note documents the end of the WGLC for the 
document below on 17th October 2009. The judgment is that this document 
is ready for publication and that there is  WG consensus for publishing 
this document.

The current version is at:

http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-12

I shall act as the document shepherd, replacing Magnus Westerlund in 
this role (although I expect him to be the responsible AD). In preparing 
the write-up requesting publication I identified a number of issues 
(below). I shall now work with the authors to promptly conclude this and 
agree a proto write-up. Hopefully we'll soon see this back with the IESG.

Gorry

====================

Substantive comments:

---
Section 8.2    [I-D.rahman-rtg-router-alert-considerations]:
- It seems that the RAO document has been updated. Please check the 
latest version:
http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-03
and ensure there is no conflict with this document in  the new sections 
on use in controlled environments.
---
Abstract:
- This is a minor comment, but careful wording of the abstract could be 
essential to progressing this:
/Based on current security concerns, these extensions are targeting
    applicability within a single domain./

- Could this say
/are targeting/ should this be /target/
- Or better say:
/Based on current security concerns, these extensions are specified
    for use within a single domain./

- This still leaves me a question about what is the /domain/, is there 
any way to qualify this as an RSVP admission control domain or 
something? suggestion welcome?

====================

NiTs:

---
Section 1:
/ As
    an example, entities involved in session control (such as SIP user
    agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
    session control protocol in use) /
This seems convoluted, could you say something like:
/ As
    an example, entities involved in session control (such as a user
    agent that uses the Session Initiation Protocol (SIP) [RFC3261]) /
---
Section 1: On page 4:
/   that can be signaled in RSVP so that network node may take into/
                                          ^
- insert "a"
---
Section 1: On page 4:
/can enforce selective bandwidth admission control decision based /
              ^
- insert "a" or change /decision/ to /decisions/ ?
---
Section 1: On page 5:
/allocation models which/
                    ^^^^^
- Change to /that/
---
Section 1: On page 5:
/these extensions are targeting/
                   ^^^^^^^^^^^^^
- change to /target/
---
Section 4.2.1:
/When POLICY_DATA objects are protected by integrity, /
                                           ^^^^^^^^^^^
- Integrity what (I didn't understand this)? - where are the integrity 
checks?
---
Section 4.2.1:
/   In case of multicast, when POLICY_DATA objects are not protected/
       ^
- add "the" ?
---
- and later in the sentence:
/protected by integrity/
                        ^
- insert "mechanisms"?
---
Section 4.2.1:
- do we need the MUST here, it seems to belong in the rule?
/When they do
    merge those, LPDPs MUST do so according to the following rule/
- is this clearer?
/When an LPDP merges elements, they must use the following rule:/
----
Section 4.3:
/ so that those can traverse /
           ^^^^^
- I think this should be /these/.
---
Section 4.3:
/policy-capable nodes that do not recognized a particular/
                                            ^
- perhaps better as?
/policy-capable nodes that do not recognize a particular/
----
Section 4.3, final para:
/so that those can/
          ^^^^^
- I think this should be /these/.
---
Section 4.3, final para:
/thes extensions defined in the present document/
     ^                       ^^^^^^^^^^^^
- delete "s"
- replace /the present/ by /this/?
---
Section 5:
/Those are discussed/
  ^^^^^
- I think this should be /these/.
---
Section 5, para 2:
/consequences on the use of IP/
               ^^^
- /on/ should be /arising from/
---
Section 5, para 2:
/As mentioned earlier, based on current security concerns (some of
    them associated with RAO), the extensions defined in this document
    are targeting applicability within a single domain./
- Would seem to me to be clearer as something like:
  /Current security concerns (some associated with use of RAO) have 
resulted in the extensions defined in this document being specified for 
use within a single domain./
---
Section 5:
/The second mechanism relies on the
    INTEGRITY object within the POLICY_DATA object to guarantee integrity
    between RSVP Policy Enforcement Points (PEPs) that are not RSVP
    neighbors./
- can you supply a reference (if there is one available)?
---
Section 5.2:
/   by an implementation of teh present document.
                             ^^^
- /the/
---
Section 6:
/ [RFC5226]) ./
             ^
- delete space.
---
Appendix
/This may include the ability to
    "queue" session requests when those can not be immediately/
                                  ^^^^^
- should this be /they/
---
/We only mention below the RSVP policy elements that are to be
    enforced by PEPs. /
- try:
/This appendix only describes the RSVP policy elements to be
    enforced by PEPs./
---
The wording in these lists could be slightly improved, e.g.:
/   o  using "Resource-Priority" header in SIP/
             ^
- insert "the"
---
/   o  not using Admission-Priority Policy Element in RSVP/
        ^^^^^^^^^
- insert "the" or rephrase as /without using the/
---
/  o  not using Preemption Policy Element in RSVP/
        ^^^^^^^^^
- insert "the" or rephrase as /without using the/
---
- same editorial comment on the following lists.
---

---

From: ken carlberg <[email-masked]>
Date: Sat, 7 Nov 2009 08:09:33 -0500

Hi Gorry,

thanks for the careful review.

> Abstract:
> - This is a minor comment, but careful wording of the abstract could  
> be essential to progressing this:
> - This still leaves me a question about what is the /domain/, is  
> there any way to qualify this as an RSVP admission control domain or  

my co-authors may have a different take on this, but I have a  
preference on keeping the word "target" within the text.  If more  
clarification is needed, perhaps the phrase "targeted deployment" is  
more appropriate.

Some members of the IESG are insistent that the focus of this  
extension be constrained within a domain because that is how they  
envision its potential deployment.  However, the RSVP protocol is  
agnostic to domains.  The specification of the base protocol does not  
make a distinction or have knowledge of administrative boundaries, and  
our specification doesn't touch on this subject, which kind of  
explains your final line of questions.

If members of the IESG have questions/concerns about deployment, then  
lets constrain our text along those lines.

cheers,

-ken