Re: [CCAMP] comments/questions on draft-ietf-ccamp-lsp-attribute-ro

[Cyril Margaria <[e-mail]>]

Hi,

Thank you for the comments, we believe we did address all of them in the
new version we posted:
URL:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-attribute-ro-05.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/
Htmlized:
http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-05

please find answers to individual comments inline.

Best Regards,
Cyril


On 3 October 2014 16:06, Lou Berger <[e-mail]> wrote:

> Hi,
>         At the last meeting it was mentioned that folks should take a look
> at
> draft-ietf-ccamp-lsp-attribute-ro in anticipation of an upcoming LC.
> Consequently, I took a re look at the document and have some
> comments/questions (for authors/contributors/WG/...):
>
> - You have a couple of editorial notes in the document, do these still
> apply or should they be dropped.
>
> They should be dropped, we cleaned-up the notes.


> - There are cases where you use 2114 language in lower case (e.g.,
> section 3.1).  As I've mentioned before on the list, such usage, even
> when correct, often leads to unneeded discussion during IESG review, I'd
> suggest avoiding lower cases usage wherever possible.  That said, I
> think you have some cases where upper case was intended.
>
>
We changed the language to be RFC2114 compliant.




> - In section 3.1, 3.3 you are giving the definition for fields (length
> and type) that are defined in 3209.  You should just point to that
> definition rather than seeming to provide the authoritative definition
> in this document.
>
> Agree


> - In section 3.2, you are similarly doing this for the Attribute TLV
> defined in section 3 of 5420.  Why not just include the reference and
> the (re)definition?
>
> Agree


> - Section 4. Isn't recording applicable to required  attributes as well?
> I.e.,why no R bit recording in section 4.1?
>
>
RFC5420 does not make that distinction in the RRO attribute subobject,
In addition the R bit is known to the node that inserted that ERO
subobject  and the requiered presence of the attribute depends on the given
attribute.
For those reasons we did include the R bit in the RRO_HOP_ATTRIBUTE. If
there is a use case for it, we will include it.



> - I think it would be good to have a compatibility section / discussion
> which should at least discuss how to deal with the now two ways to
> encode / record attribute flags. -- This document could replace
> (deprecate) the old way, but this document would then need to be an
> update to 5420...
>
>
We added a section on compatibility.
We see that both are compatible, the RFC5420 one should be used to report
if an RFC5420 attribute has been processed, a node is allowed to use
RRO_HOP attribute to report a LSP attribute value, but this must be in
addition to the RFC5420 RRO attribute recording.

for ro attributes, the node SHOULD use the RRO_HOP and SHOULD NOT use the
RFC5420 mechanism if no LSP_ATTRIBUTE is present.



> - The IANA section needs to be updated with the proper format.  See
> RFC5226.  draft-ietf-ccamp-rsvp-te-srlg-collect-07 is good example (but
> don't include values and use the non-xml version of the registry links.)
>
> We updated the IANA section to match more closely the register format.



> - Section 6 won't make it through the IESG.  Again
> draft-ietf-ccamp-rsvp-te-srlg-collect-07 is good example of recent
> language produced by the WG, and is a fine starting point.
>
> We filled the Security section


> I think that's it.
>
> Thanks again for your review.


> Lou
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>