I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-irtf-mobopts-l2-abstractions-04.txt
Reviewer: David L. Black
Review Date: November 27, 2007
IETF Telechat Date: November 29, 2007
Summary:
This draft is on the right track, but has open issues,
described in the review.
Comments:
The draft defines a functional interface framework for
L2/L3 interactions that can be used to support fast
Mobile IP Handover. As a framework draft, it necessarily
omits details such as parameter syntax, which is ok.
While the draft is generally well written and technically
solid, it has a serious terminology collision that
unfortunately rises to the level of an open issue:
- Section 3 defines four "primitives" that are the basic
interaction between layers. For example, the "Request"
primitive is usually sent from a Layer to a Lower Layer,
and will be responded to by a "Confirm" primitive
returned from the lower layer.
- Section 4 defines nine "primitives" that are constructed
from the four "primitives" defined in Section 3. For
example, the L2-LinkStatus primitive consists of
a request primitive (L2-LinkStatus.request) followed
by a confirm primitive (L2-LinkStatus.confirm).
As can be seen from these examples, sections 3 and 4 are clear
as written. The problems occur later in the document when
the word "primitive" (usually the plural "primitives") is
used without qualification - it is unclear whether such
usage refers to the Section 3 primitives, the Section 4
primitives or both (I believe "both" is usually intended).
I strongly suggest that a word other than "primitive" be
chosen for the Section 3 Request, Confirm, Indication and
Response concepts in order to distinguish them from the
Section 4 concepts and that the draft be revised accordingly.
I also found one minor issue: Section 3 describes Type 2
primitives as using a Request followed by a Confirm and
an asynchronous Indication. Tex should be added about
ordering or absence of ordering between the Confirm
Indications, and in particular cover at least the
following two cases:
- When a Request enables Indications, can an Indication
be received before the Confirm?
- When a Request disables Indications, can an Indication
be received after the Confirm?
These have significant implementation implications.
idnits 2.05.01 found a number of items that need attention:
Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
------------------------------------------------------------------------
----
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to http://www.ietf.org/ID-Checklist.html:
------------------------------------------------------------------------
----
** The document seems to lack an IANA Considerations section. (See
Section
2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the
case
when there are no actions for IANA.)
** The document seems to lack separate sections for
Informative/Normative
References. All references will be assumed normative when checking
for
downward references.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC
2119
keywords.
RFC 2119 keyword, line 218: '...es of primitives MUST be exchanged
for...'
RFC 2119 keyword, line 227: '...ses of primitive MUST be exchanged
and...'
RFC 2119 keyword, line 228: '..."Response" class MAY be exchanged
for ...'
RFC 2119 keyword, line 237: '... primitives MUST be exchanged
for...'
The incorrect guess that Proposed Standard is the Intended
Status caused idnits to report a lot of possible reference problems.
Only the following appear to need actual attention by the authors:
== Missing Reference: '9' is mentioned on line 523, but not defined
-- Possible downref: Undefined Non-RFC (?) reference : ref. '9'
== Missing Reference: '10' is mentioned on line 528, but not defined
-- Possible downref: Undefined Non-RFC (?) reference : ref. '10'
== Missing Reference: '11' is mentioned on line 538, but not defined
-- Possible downref: Undefined Non-RFC (?) reference : ref. '11'
These are actually syntax problems throughout Sections 7 and 8 -
when [3] is used to cite a reference, [3] should not be used to
introduce a numbered paragraph, (3) is a better substitute.
== Outdated reference: draft-iab-link-indications has been published
as RFC
4907
** Downref: Normative reference to an Informational draft:
draft-iab-link-indications (ref. '7')
The Downref problem is caused in part by the draft's failure to divide
its references into Normative and Informative references. Reference 7
is clearly informative, as a number of the other references. The entire
reference list needs to be split into normative and informative.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
