Ethernet Traffic Parameters
draft-ietf-ccamp-ethernet-traffic-parameters-10

[Ballot discuss]
The document has this text:

          The permitted Ethernet Link Type values are:
   
            Value  Switching Granularity
            -----  ---------------------
              0    Provided in signaling. See [GMPLS-ESVCS]
              1    Ethernet Port (for port-based service)
              2    Ethernet Frame (for EVC-based service)
            255    Reserved value
   
          Values 0 through 239, and 255 are assigned by IANA via IETF
          Standards Action. Value 255 is reserved by the
          present document.

I think this should be "Values 3 through 239 are assigned by IANA via
Standards Action [RFC5226]. Value 255 is reserved by the present
document." There is no need to assign values that have already been
assigned (such as 0-2 and 255).

Also, entries values 0, 1, and 2 should have a reference above.
It is this document, but I am actually not sure where in this
document their definition can be found.

Finally, there is confusing overlap with Section 9. It would be
perhaps better to specify the actual behaviour and formats in this
section and the IANA rules only in Section 9. My comments apply to
both the IANA section and this text, however.

The document has this text:

            Type    Length  Format            Description
            ------------------------------------------------------
              0      TBD    Reserved          Reserved value
              1      TBD    Reserved          Reserved value
              2        24    see Section 3.1  Ethernet Bandwidth
                                                Profile [MEF10.1]
              3        8    [GMPLS-ESVCS]    Layer 2 Control
                                                Processing (L2CP)
            255      TBD    Reserved          Reserved value

I am not sure I understand why Length values can be "TBD". TBD values
need to be filled in before the RFC comes out, did you intend to have
IANA fill them, or does TBD stand for "not applicable" or "any value
is acceptable here"?

Also, this list has similar issues to the one shown above.

Section 4.1 has this text:

        The Flag 2 (CM) indicates whether the color-aware or color-
        blind property is employed by the bandwidth profile. When Flag
        2 is set to value 0 (1), the bandwidth profile algorithm is
        said to be in color blind (color aware) mode.

I would like to see a reference to what the color-aware/blind property
is.

[Ballot comment]
In a number of cases the following text is used to describe the assignment status of code points "Values 256 through 65535 are not to be assigned at this time." It would be useful to forward reference the IANA section which actually specifies this as "Standards Action"

Alternatively the authors could omit all the policy statements from the body text (which duplicates the IANA section) and put the policy in one place (the IANA section).

[Ballot comment]
In section 8, the first paragraphs is "This document introduces no new security considerations to either [RFC3473]."  The word "either" implies there was another RFC listed.  Should "either" be removed from the sentence or should another RFC be added?

[Ballot comment]
In section 8, the phrase "to either" in the first paragraph implies there was another RFC listed.  Should "either" be removed from the sentence or  should another RFC be added?

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following
assignments in the "Class Names, Class Numbers, and Class Types"
registry at
http://www.iana.org/assignments/rsvp-parameters

Class Number Class Name Reference
------------ ----------------------- ---------
9 FLOWSPEC [RFC2205]

Class Type (C-Type):

6 Ethernet SENDER_TSPEC [RFC-ccamp-ethernet-traffic-parameters-10]


Action #2:

Upon approval of this document, IANA will make the following
assignments in the "Class Names, Class Numbers, and Class Types"
registry at
http://www.iana.org/assignments/rsvp-parameters

Class Number Class Name Reference

------------ ----------------------- ---------
12 SENDER_TSPEC [RFC2205]

Class Type (C-Type):

6 Ethernet SENDER_TSPEC [RFC-ccamp-ethernet-traffic-parameters-10]


Action #3:

Upon approval of this document, IANA will create the following registry
at
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml

Registry Name: Ethernet Switching Granularities
Registration Procedures: Standards Action

Initial contents:

Value Switching Granularity Reference
----- -------------------------------------- ----------
0 Provided in signaling. [draft-berger-ccamp-gmpls-ether-svcs]
1 Ethernet Port (for port-based service)
[RFC-ccamp-ethernet-traffic-parameters-10]
2 Ethernet Frame (for EVC-based service)
[RFC-ccamp-ethernet-traffic-parameters-10]
3-239 Unassigned
240-254 Reserved for Private Use
255 Reserved [RFC-ccamp-ethernet-traffic-parameters-10]
256-65535 Reserved; range can be made available by Standards Action
[RFC-ccamp-ethernet-traffic-parameters-10]


Action #4:

Upon approval of this document, IANA will create the following registry
at
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml

Registry Name: Ethernet SENDER_TSPEC TLVs
Registration Procedures: Standards Action

Initial contents of this sub-registry will be:
Type Description Reference
----- -------------------------------- ---------
0 Reserved Value [RFC-ccamp-ethernet-traffic-parameters-10]
1 Reserved Value [RFC-ccamp-ethernet-traffic-parameters-10]
2 Ethernet Bandwidth Profile [RFC-ccamp-ethernet-traffic-parameters-10]
3 Layer 2 Control Processing (L2CP)
[RFC-ccamp-ethernet-traffic-parameters-10]
4-239 Unassigned
240-254 Reserved for Private Use
255 Reserved [RFC-ccamp-ethernet-traffic-parameters-10]
256-65535 Reserved; range can be made available by Standards Action
[RFC-ccamp-ethernet-traffic-parameters-10]


Action #5:

Upon approval of this document, IANA will create the following registry
at
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml

Registry Name: Ethernet Bandwidth Profiles
Registration Procedures: Standards Action

Initial contents of this sub-registry will be:

Bit Hex Description Reference
--- ---- -------------------------- -------------
0 0x01 Coupling flag (CF) [RFC-ccamp-ethernet-traffic-parameters-10]
1 0x02 Color mode (CM) [RFC-ccamp-ethernet-traffic-parameters-10]
2-7 Unassigned

We understand the above to be the only IANA Actions for this document.

Proto-write-up for draft-ietf-ccamp-ethernet-traffic parameters-09.txt

Intended status: Proposed Standard

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Deborah Brungard is the document shepherd.
She has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The I-D has had a good level of discussion and review. Several liaisons
were exchanged with IEEE, ITU-T, and MEF during CCAMP's Ethernet work to
ensure compatibility and cooperation between the SDOs.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR disclosures have been filed.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

WG consensus is solid.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No threats.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

All checks made. A verbose check error on lines being too long.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

One reference to a document in the process of publication.
References split. No downrefs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA section looks good.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No formal language is used.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document describes the support of Metro Ethernet Forum (MEF)
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

There are no known implementations, but it is expected that several
vendors plan to implement.