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

From: Lou Berger <[email-masked]>
Date: Fri, 03 Oct 2014 16:06:37 -0400

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.

- 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.

- 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.

- 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?

- Section 4. Isn't recording applicable to required  attributes as well?
I.e.,why no R bit recording in section 4.1?

- 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...

- 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.)

- 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.

I think that's it.

Lou

---

From: Cyril Margaria <[email-masked]>
Date: Fri, 24 Oct 2014 12:37:41 -0400

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 <[email-masked]> wrote:

> They should be dropped, we cleaned-up the notes.

> think you have some cases where upper case was intended.
We changed the language to be RFC2114 compliant.

> Agree

> Agree

> 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.

> (deprecate) the old way, but this document would then need to be an
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.

> We updated the IANA section to match more closely the register format.

> We filled the Security section

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

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Oct 2014 14:49:04 -0400

Cyril, Authors,
    Thank you for the update.  See below for one response. 

Do you have any outstanding actions/plans on the draft or do you believe
it is
ready for LC?

Thanks,
Lou
On 10/24/2014 12:37 PM, Cyril Margaria wrote:
>
> Hi,
>
> Thank you for the comments, we believe we did address all of them in
> the new version we posted:
> URL:           
> On 3 October 2014 16:06, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> ...
>
> subobject  and the requiered presence of the attribute depends on the
> given attribute.
> or those reasons we did include the R bit in the RRO_HOP_ATTRIBUTE. If
I guess this could be argued either way.  From a technical perspective,
I think the information is useful and you're already carrying the bit. 
Then again, from the process standpoint, if no one else thinks this is
needed, I don't want my comment to trigger the change.

...