Last Call Review of draft-ietf-ccamp-gmpls-ospf-g709v3-09
review-ietf-ccamp-gmpls-ospf-g709v3-09-genart-lc-sparks-2013-10-11-00
| Request | Review of | draft-ietf-ccamp-gmpls-ospf-g709v3 |
|---|---|---|
| Requested revision | No specific revision (document currently at 13) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2013-10-16 | |
| Requested | 2013-10-03 | |
| Authors | Daniele Ceccarelli , Fatai Zhang , Sergio Belotti , Rajan Rao , John Drake | |
| Draft last updated | 2013-10-11 | |
| Completed reviews |
Genart Last Call review of -09
by
Robert Sparks
(diff)
Genart Telechat review of -11 by Robert Sparks (diff) Secdir Last Call review of -09 by Phillip Hallam-Baker (diff) |
|
| Assignment | Reviewer | Robert Sparks |
| State | Completed | |
| Review |
review-ietf-ccamp-gmpls-ospf-g709v3-09-genart-lc-sparks-2013-10-11
|
|
| Reviewed revision | 09 (document currently at 13) | |
| Result | Ready with Nits | |
| Completed | 2013-10-11 |
review-ietf-ccamp-gmpls-ospf-g709v3-09-genart-lc-sparks-2013-10-11-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
draft-ietf-ccamp-gmpls-ospf-g709v3-09
Reviewer: Robert Sparks
Review Date:
11-Oct-2013
IETF LC End Date:
16-Oct-2013
IESG Telechat date: Not yet scheduled for a telechat
Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.
This document is dense (as in it puts a lot of information in a
small number of characters), but it reads clearly.
I did not carefully review the contents of the example fields for
editorial mistakes - please be sure someone in the group has done
that.
The largest issue I see is on the border of being more than a nit.
I'm calling it a nit because it should be very easy to fix:
The sentence "Same type of modification needs to applied to the
IANA-GMPLS-TC-MIB at
https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib
" is
not sufficient instruction to IANA to cause that registry to be
modified. Please provide more precise
instructions as to how this mib should change.
I note also that the value 40 from RFC6060 didn't make it into the
mib.
The rest of these are more nitty nits:
---
In section 4, I think you've repeated a MUST, and risk introducing
confusion.
It's awkward to point to this with paragraph numbers because of the
interspersed tables, so I'll quote the relevant block:
When supporting the extensions defined in this document, the
Switching Capability and Encoding values MUST be used as follows:
- Switching Capability = OTN-TDM
- Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
Both for fixed and flexible ODUs the same switching type and encoding
values MUST be used.
If I read that correctly , those are the same MUST and you're saying
it's a MUST no matter whether you're talking about fixed or flexible
ODUs.
If that's correct I suggest replacing this with:
When supporting the extensions defined in this document, for both
fixed and flexible ODUs, the Switching Capability and Encoding values
MUST be used as follows:
- Switching Capability = OTN-TDM
- Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
(or leave out the fixed and flexible clarification altogether - I
would not have been confused without it).
---
In section 8.2, where you say "IANA will create and maintain a new
registry", I suggest you say "new sub-registry".
RjS