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

[OSCAR GONZALEZ DE DIOS <[e-mail]>]

Hi Lou,

        Lots of thanks for the revision made to the SRLG collection draft.

        We have recently posted a new version addressing the comments mentioned
in your review, and some additional comments.

        The IETF datatracker status page for this draft
is:     https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/

        There's also a htmlized version available at:
        http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-05

        A diff from the previous version is available at:
        Http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-srlg-collect-05


        There are no idnits in the new version, as can be checked in
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-
rsvp-te-srlg-collect-05.txt

        The main changes are:

        * No idnits
        * Replace head with ingress
        * Replace tail with egress
        * Section 3 changed to Encodings
        * Added Reserved field in section 3.2
        * Added length in fields in section 3.2
        * Rewording of text at beginning of SRLG Collection procedure.
        * sets to MUST set.
        * which can be carried to which MAY be carried
        * if to when in specific examples
        * some more wording changes
        * "Section 5.3 Compatibility² added
        * References fixed
        * RRO ordering discussed
        * added RFC5420 as a normative reference
        * References in normative /informative


        Authors believe most of the comments have been addressed.

        Best Regards,

                Óscar & draft-ietf-ccamp-rsvp-te-srlg-collect-05 authors.




El 07/05/14 23:53, "Lou Berger" <[e-mail]> escribió:

>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
>
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição