Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

From: "Yemin (Amy)" <[email-masked]>
Date: Mon, 8 Apr 2019 09:49:31 +0000

Hi Paul, 

In 3.10 of RFC2205, e.g., Unknown C-Type for Known Class, 
"Generally, the appearance of an object with unknown C-Type should result in rejection of the entire message and generation of an error message (ResvErr or PathErr as appropriate)."
It use "should" but in lower case. 
 
In additional to RFC2205, RFC5711 defines "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages".
In section 2.1 of RFC5711, 
"In the case of fatal errors ("Hard Preemption"; see Section 4.7.3 of [RFC3209] ), the detecting node MUST send a PathErr message reporting the error condition, ....  
In the case of non-fatal errors, the detecting node should send a PathErr message, and must not clear control plane or data plane state. "

Considering the case in this draft, such error can be considered as non-fatal error (the path can still be set up disregarding the Availability TLV), thus SHOULD is more appropriate here.  

BR,
Amy
-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, March 29, 2019 1:10 AM
To: [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: 2019-04-09

Summary:

This draft is on the right track but has open issues, described in the review.

Issues:

Major: 0
Minor: 1
Nits:  0

1) MINOR (maybe MAJOR):

Section 3.2 includes the following:

     When a node does not support the Availability TLV, it SHOULD
     generate PathErr message with the error code "Extended Class-Type
     Error" and the error value "Class-Type mismatch" (see [RFC2205]).

This seems to be placing a normative requirement on implementations of RSVP that *don't* support this document. That is clearly impossible.

I am guessing that this is the standard normative behavior for implementations of RSVP that encounter a TLV type they don't understand. 
(I tried to find this in RFC2205 but failed.) If so, then this section should be reworded to indicate that this is the behavior that will occur rather than a new normative requirement.

OTOH, if this is not the standard handling for unknown TLV types then you need to rethink this.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 10 Apr 2019 16:26:20 -0400

Paul, thanks for your review. Amy, thanks for your response. Benjamin filed a DISCUSS on this point, which I support. I think based on the text you quote from RFC 2205, normative language to describe the error handling here is not appropriate. I entered a No Objection ballot in support of his DISCUSS.

Alissa

> On Apr 8, 2019, at 5:49 AM, Yemin (Amy) <[email-masked]> wrote:
> 
> Hi Paul, 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 11 Apr 2019 10:20:45 +0000

Thank you, Alissa.
We will change it to informative text. 

BR,
Amy
________________________________________
发件人: Alissa Cooper [[email-masked]]
发送时间: 2019年4月11日 4:26
收件人: Yemin (Amy); Paul Kyzivat
抄送: [email-masked]; General Area Review Team
主题: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

Alissa