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 protected]]
Sent: Friday, March 29, 2019 1:10 AM
To: [email protected]
Cc: General Area Review Team <[email protected]>
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
