Re: Chair review of draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

["Adrian Farrel" <[e-mail]>]

Hi Deborah,

Thanks for your review.
I have updated the draft as follows...

> =======
> Boilerplate
> Need the new boilerplate

Looks like a couple of non-mandatory boilerplate changes flagged by idnits.
I have made the updates.

> =======
> Nits: may want to check, a couple of nits on weird spacings and line
> lengths

No problems in the new revision.
Looks like maybe some idnits bugs for the previous revision.

> =======
> Section 1
> Update for recent work, e.g. [INTER-DOMAIN-FRAMEWORK] is RFC4726,
> RFC4726 applies for MPLS-TE and GMPLS,

Thanks. Yes.

> requirements for GMPLS are in draft-otani-ccamp-interas-gmpls-te-05.txt.

Well, I'll leave that for now as it is not specific to this work.

> =======
> Section 2
> text has "supported by one of three options"
> May want to also mention 4726's hybrid support, probably a small note
> is all that's needed, e.g. "(or hybrid)".

Yes. Text added to section 2.

> Also, it would be useful to
> mention something on consideration for 4726's backward compatibility,
> either here or in a later section.

Yup. New section 7 added to cover backward compatibilty.

> =======
> Section 3
> item 2 incomplete sentence, a suggestion:
> s/adhered to./adhered./

I'll leave that sort of thing to the RFC Editor to worry about.

> also in item 2
> s/message an error code/message with error code/

Yes

> item 3
> s/in the Section 3/in Section 3/

Yes.

> item 4
> s/option is supplied/option is specified/

Yes

> =======
> Section 3.2
> s/information that report/information that reports/

Yes

> =======
> Section 5.1.2
> s/(filed link)/(failed link)/

Yes. (A favorite typo of mine!)

> =======
> Section 5.1.3
> s/domian/domain/

Yes

> =======
> Section 6
> s/preferable/more preferred/

Yes

> s/in order search/in order to search/

Yes

> =======
> Section 7
> s/:-/:/

Yes

> the text says "disallow or ignore hops", I don't think its "ignore"?

I think it is ignore.
The policy is that a node outside the domain cannot specify the path of the 
LSP inside the domain. The domain border LSR can make implement this policy 
in one of two ways:
- It can reject the Path message
- It can ignore the hops in the ERO that lie within the domain

I have added this clarification.

> ======
> [LOOSE-REOPT] is now [RFC4736], and Informational, did you want to
> reference as a Normative Reference?

Good catch!

> Check and update others.

Checked

> ======
> Section 11
> JP's email address is up-to-date?

JP is ambidextrous. He can receive emails with both hands at the same
time.  :-)


Cheers,
Adrian