Hi Dimitri,
Looking at your response to David Black's review, I think an update to the
draft is needed. I'd like to get it onto an IESG agenda before Anaheim as it
has several Ethernet drafts backed up behind it.
Sections 5.1.4, 5.2.1 and 8 have me confused about the
Attributes Flags TLV:
- Section 5.1.4 defines an Attributes Flags TLV here
for Virtual TE links: the CALL ATTRIBUTE is defined in this document
- Section 5.2.1 points to RFC 5420 for what's apparently a different
Attributes Flags TLV and defines a Pre-Planned LSP flag in
that TLV.
for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to
introduced a new flag
- Section 8 then apparently instructs IANA to put that bit into the
Attributes Flags TLV defined in Section 5.1.4 .
Something appears to be wrong with this combination - what was
the intent? If these two TLVs are the same, or share a common bit
assignment registry, that should be stated.
I will clarify this because as they both refer to "attributes" precision
of the terms
used is indeed critical
I think David is quite right that there is confusion. My understanding is as
follows...
There are two separate objects: the Call_Attribute object and the
LSP_Attribute object.
Both of these objects can carry a TLV called the "Attributes Flags TLV". But
this is a DIFFERENT TLV for the two objects. In the first case, it is for
use in the Call_Attribute object and is defined in this document. In the
second case it is for use on the LSP_Attribute object and is defined in RFC
4020 with this document only defining a new flag.
My suggestion to make this crystal clear is to change the name of the
Attributes Flags TLV carried in the Call_Attribute object to be the "Call
Attibutes Flags TLV". I think this is a really easy search and replace, and
fixes this issue.
David also said...
The IACD sub-TLV formats for OSPF and IS-IS appear to be
identical. If they are in fact identical, a single ASCII text diagram
should be used for both.
They are identical, but that is only good fortune. There is no requirement
that they be the same, and there is no required mapping between the two.
Furthermore, a future revision might need to change the format or content
for one protocol, but not for the other, etc. Thus, we prefer to keep the
definitions distinct.
The description of the IACD sub-TLV format does not describe the
Max LSP Bandwidth fields. At a minimum the units and/or encoding of
these fields should be described here, even thought the full
specification may be elsewhere.
David is correct that the fields should be mentioned, but I think it would
be OK to include a reference to RFC4203 and RFC5307.
Please add the values for Type and Length for the XRO SC
subobject into the ASCII figure in Section 4.1.1 .
The convention in RSVP-TE is to not include the Type and Length (most
relevantly, see RFC 4874). It would be inappropriate to change that
convention here.
Section 4.1.2 defines a new subobject by making minor changes to an
existing one in another RFC; a complete ASCII diagram of the new
subobject would be helpful - please add one.
There is absolutely no change in the format of the subobject. The only
difference is the interpretation of the L bit. In order to keep the
subobjects in lock-step, it is preferable to not include a further ASCII
diagram.
idnits 2.12.00 found three nits:
== The page length should not exceed 58 lines per page, but
there was 1 longer page, the longest (page 1) being 62 lines
This is the first page caused by leading several CRLF
** There are 144 instances of too long lines in the
document, the longest one being 1 character in
excess of 72.
Seems to be a product of MS Word.
I think the whole thing needs to be left-shifted by 7 spaces.
== Line 781 has weird spacing: '...ndwidth is st...'
Yup. Section 5.2.2 para 2 has a double space.
Finally, could you or Lou please confirm the IANA actions in the email from
Amanda on the 16th.
Many thanks,
Adrian
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
