[CCAMP] Comments on draft-ietf-ccamp-rsvp-te-srlg-collect-04

[Lou Berger <[e-mail]>]

Hi,
    Here are some primarily editorial suggested changes to / comments on
draft-ietf-ccamp-rsvp-te-srlg-collect-04.  Please use/respond as you
see appropriate.

- The draft has a bunch of idnits issues which need to be fixed
  see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rsvp-te-srlg-collect-04.txt
  (I'll use line numbers from this URL below.)

- I suggest, in the whole document
    s/head/ingress
    s/tail/egress

- Section 3 title: "RSVP-TE Extensions (Encoding)"
  The whole document is an RSVP-TE Extensions, so this isn't a very
  useful section heading.  How about just calling the "Encodings"

- Section 3.2
  - Each field should have its length defined
  - The reserved field needs to be defined

Section 4.1

-  lines 179-181:
   Typically, the head node gets the route information of an LSP by
    adding a RRO which contains the sender's IP addresses in the Path
    message.

  - Given this is defined in RFC209, how about:

   Per RFC 3209, an ingress initiates the recording of the route
    information of an LSP by adding a RRO to a Path message.

- There are places where the section is light on 2119 language:
  - line 181: s/it sets/it MUST set
  - line 182: s/which can be carried/which MAY be carried

- lines 183/4: Given you are describing specific cases, s/if/when in the
  following:

   either in an LSP_REQUIRED_ATTRIBUTES Object if the collection is
   mandatory, or in an LSP_ATTRIBUTES Object if the collection is

- drop "is" in "...  Collection Flag is set" (lines 188 and 196)

- you use "should not" in lower case in a few spots in this section.
  While I think your usage *is* correct, my experience is that someone
  (probably in the IESG) will tell you that these need to be in upper
  case at some point.  Of course, they'll be wrong, and this will have
  to be explained.  I suggest avoiding 2119 language in lower case where
  easily avoided.  How about s/should not be/is not to be

- Line 200: " the SRLG sub-object(s) in the Path RRO."
  How about "any SRLG sub-object(s) in the RRO of the corresponding
  outgoing Path message."

- Line 202: s/If/When the Collection Flag is set and

- Line 203/4:
  OLD
       processing node SHOULD add an SRLG sub-object to the RRO to carry the
       local SRLG information.
  NEW
       processing node SHOULD add local SRLG information, as defined
       below, to the RRO of the corresponding outgoing Path message.

- Line 208: s/forwarding/processing

- line 210:
  OLD
      node can get the SRLG information from the RRO
  NEW
       node receives SRLG information in the RRO

- Lines 212-215 - this needs to be rephrased into language with which an
  implementation may conform.  How about something like:

    Per RFC 3209, when issuing a Resv message for a Path message which
    contains an RRO an egress node initiates the RRO process by adding
    an RRO to the outgoing Resv message.  The processing for RROs
    contain in Resv messages then mirrors that of the Path messages.

- Line 224: s/must not/MUST NOT

- Lines 225-7
 OLD
   Otherwise, if local policy allows to provide the SRLG
   information, it MUST add an SRLG sub-object to the RRO to carry the
   SRLG information in the upstream direction.
 New
   When local policy allows recording SRLG
   information, the node SHOULD add SRLG information, as defined below,
   to the RRO of the corresponding outgoing Resv message.

- Lines 246-250.  I don't think such informative text belongs in this
  section.  I also think it's redundant with the last paragraph of
  section 1 so suggest dropping it altogether.

- The section is missing handling of RRO to big. Perhaps add it at ~line
  330.

Section 4.2
 - Line 260: s/need not/SHOULD NOT

Section 4.3 Compatibility (?)
- Need a section covering what happens when an existing implementation
  sees a flag or SO defined in this document.  (Remember, you can't
  specify their behavior, just say what they should be expected to do
  based on current RFCs and the objects defined in this document.)

- Section 5
  The section doesn't cover the possibility of SRLGs being
  mapped/changed from/to internal to/from neighbor SRLG values.

- Section 6
  Section 5 implies there is a policy decision to be made at border
  nodes. It seems to me that the security related considerations of this
  policy decision should be covered in the document. Either in this
  section or in section 5, in which case this section should point to
  that discussion.

- Section 9
  The references need to be split into informative and normative
  references.  For example, all but the first two references look
  informative to me.

That's it,
Lou