I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.
Please always CC <mailto:tsv-dir@xxxxxxxx>tsv-dir@xxxxxxxx if you
reply to or forward this review.
Summary:
This is a well written, concise and needed modification to MPLS.
That said, I don't understand why the 1st minor issue below is
present. Recommend (fairly strongly) adding the
"Document Updates: RFC 3031, RFC 3032"
as mentioned below on this first page of this RFC to be.
Transport Issues:
There are no issues
minor issues:
- S2 "Motivation", last sentence is
"We believe that this document adds
details that have not been fully addressed in [RFC3031] and [RFC3032]
as well as complements [RFC3270], [RFC3443] and [RFC4950]. "
I find it surprising that this document does not formally update 3031
and 3032, given that it is mandatory to implement, optional to
invoke. ISTM, as an outsider to MPLS, this would in fact be the case
given the impact of/to IP stacks not adhering to this proposed standard.
- Section 5.2 is about Router Alert Options, and states "At the time
of this writing ...". I wonder if this subsection is valid, or needs
another review against this IntArea ID
http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02
to still be valid in a month or two once the IntArea ID (currently in
WGLC) is processed by the IESG and RFC-Editor?
IMO - these two docs are progressing near enough to each other to
each consider what the other says - with or without a normative or
informative reference in either or both docs to the other.
nits:
- I'm surprised to see the Abstract on page 2. I thought we
collectively fixed the case in which the Abstract can be on any page
other than page 1.
- at the page Footer, in the middle of the line, there isn't a "short
document name" - which has been there on all previous well formed IDs
and RFCs that I have seen (which of course is not all of them). It is
recommended the authors pick a short form name for the subject of
this doc for this location, such as
LER Header Option Behaviors
- S3, 4th para, second to last sentence is:
"First a downstream LSR may
have not have sufficient IP routing information to forward the packet
resulting in packet loss. "
recommend removing the first instance of "have". The sentence reads
better without it.
- S3, 4th para, last two sentences
list a "First" and a "Second" reason correctly, but are missing
required commas after each word (i.e., "First, ...", and "Second, ..." )
- S3, 5th para, 1st sentence is lacking commas here:
"...FEC, yet are forwarded
into an IP/MPLS network without being MPLS-encapsulated,
present..."
- S5.1, last bullet has this:
"...MPLS encapsulation at a ingress LER ..."
^^^^^
s/a/an
James
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf