Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks
draft-ietf-iporpr-basic-03

-------- Original Message --------
Subject: draft-ietf-iporpr-basic-03.txt in danger of being moved off publication track
Date: Tue, 10 Jun 2008 16:12:37 +0200
From: Mark Townsley
To: draft-ietf-iporpr-basic-03@tools.ietf.org, iporpr-chairs@ietf.org


Authors, Chair,

This document has been stuck so long that I don't hardly remember why.

If we cannot resolve Russ and Dan's discuss below, I will move this
document to DEAD status and simply assume that there is no energy to
continue the work. Same for the WG itself.

I'm putting a timeline on this. If I don't get a response back within a
month, so by July 10, I will stop the publication of this document.

- Mark

[Ballot discuss]
(Picking up the DISCUSS position from Brian Carpenter, which was in turn
partly based on Gen-ART review by Miguel Garcia)

Section 2 contains normative statements addressed to the reader,
rather than qualifying protocol features:

>  This section SHALL NOT be used as a definitive
>  description ...

and

>  IEEE 802.17 SHALL be consulted ...

Please reword to fit RFC 2119, for example:

"It is not the purpose of this section to become a replacement of the
normative IEEE 802.17 [2] or IEEE 802.17a [14] specifications."

and

"The reader is encouraged to consult IEEE 802.17 [2] and IEEE 802.17a
[14] for normative details of functionality."

or

"Implementation of the current specification MUST follow
  IEEE 802.17 [2] and IEEE 802.17a [14]."

(according to which of those you really mean).

- Section 3.3, last sentence of the section, contains some unclear
wording around the normative MAY. The text reads:

>    Note that a maximum jumbo frame payload size that MAY
>    be supported is defined at 9100 bytes.

This makes no sense as a normative statement. Why not just
change to lower case "may"?

References must be split into Normative/Informative sections.

The beginning of section 4.2 is misleading:

>  The Differentiated Service (DS) field of the IPv4 and IPv6 frame can
>  be used to convey service priority.

Explicitly, diffserv is *not* a priority mechanism; it is a mechanism
for differentiating classes of service.

Reference [8] is to an obsolete document.

Reference [9] is used as if it was normative, but [9] is informational.
Thus, Table 1 is not normative (and this draft should not replicate
material from [9] anyway, in case [9] is later updated.)

>  The mapping between IP DSCP to RPR header service class relevant
>  fields are shown in Table 2.  This is the default mapping for
>  interoperablility, vendors/operators may choose to map differently.
>  Note that four treatment aggregates are used as suggested by [10].

This isn't clear enough whether it is trying to be normative
or not. In fact its status cannot be normative, because it is
built on [9] and [9] is not normative.

This also needs to be clarified for the MPLS mapping in 6.1.1.

[Ballot discuss]
The references are not split between normative and informative.  It's impossible to check for downrefs without this split; if they're all normative then there are 9 downrefs that have to be dealt with.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following
assignment in the "ADDRESS RESOLUTION PROTOCOL PARAMETERS" registry located at

http://www.iana.org/assignments/arp-parameters

in subregistry "Hardware Type (hrd)"

TBD IEEE_802_17 [RFC-iporpr-basic-03]

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

[Ballot comment]
In the SecDir Review from Pat Cain, a rewording for the security
  considerations was suggested.  Pat proposed:
  >
  > This specifications provides no security measures as it is only an
  > encapsulation protocol. Security mechanisms shall be provided by
  > the appropriate upper-layer protocols.
  >
  Pat also points out that the sentence that follows may have to be
  tweaked for continuity too.

[Ballot comment]
1. The two introductory paragraphs in Section 2 seem to describe instructions to the reader of the document, I do not believe that they should use RFC 2119 style capitalization.

2. Some of the acronyms are not expanded at first use - FCS for example, may be more

3. in section 3.1.4 - what is the FCS computed upon?

4. section 3.2 - it would be useful to provide a reference to the registry where these value are defined

5. section 3.3 - the document should refer from what version of the IEEE 802.3 standard the max frame length is being taken - especially as this aspect of the IEEE 802.3 standard is now under revision.

[Ballot discuss]
Part of the text in Section 4.2 refers to mapping of DSCP values, per hop behavior to IP service classes and is based heavily on RFC 4594, which is Informational. I believe that this information does not belong in the normative section of a standards track document. I suggest that the information that is not related strictly to the mapping of DSCP values in the RPR frame be moved in an Annex and the informational character of the references be clearly mentioned

[Ballot discuss]
(Partly based on Gen-ART review by Miguel Garcia)

Section 2 contains normative statements addressed to the reader,
rather than qualifying protocol features:

>  This section SHALL NOT be used as a definitive
>  description ...

and

>  IEEE 802.17 SHALL be consulted ...

Please reword to fit RFC 2119, for example:

"It is not the purpose of this section to become a replacement of the
normative IEEE 802.17 [2] or IEEE 802.17a [14] specifications."

and

"The reader is encouraged to consult IEEE 802.17 [2] and IEEE 802.17a
[14] for normative details of functionality."

or

"Implementation of the current specification MUST follow
  IEEE 802.17 [2] and IEEE 802.17a [14]."

(according to which of those you really mean).

- Section 3.3, last sentence of the section, contains some unclear
wording around the normative MAY. The text reads:

>    Note that a maximum jumbo frame payload size that MAY
>    be supported is defined at 9100 bytes.

This makes no sense as a normative statement. Why not just
change to lower case "may"?

References must be split into Normative/Informative sections.

The beginning of section 4.2 is misleading:

>  The Differentiated Service (DS) field of the IPv4 and IPv6 frame can
>  be used to convey service priority.

Explicitly, diffserv is *not* a priority mechanism; it is a mechanism
for differentiating classes of service.

Reference [8] is to an obsolete document.

Reference [9] is used as if it was normative, but [9] is informational.
Thus, Table 1 is not normative (and this draft should not replicate
material from [9] anyway, in case [9] is later updated.)

>  The mapping between IP DSCP to RPR header service class relevant
>  fields are shown in Table 2.  This is the default mapping for
>  interoperablility, vendors/operators may choose to map differently.
>  Note that four treatment aggregates are used as suggested by [10].

This isn't clear enough whether it is trying to be normative
or not. In fact its status cannot be normative, because it is
built on [9] and [9] is not normative.

This also needs to be clarified for the MPLS mapping in 6.1.1.

[Ballot comment]
(From Gen-ART review by Miguel Garcia)

- Section 8, IANA Considerations. In the sake of clarity, I would suggest to reword the text as following:

  "IANA is instructed to allocate a new hardware type (hrd) for IEEE 802.17 in the Address Resolution Protocol Parameters registry, as follows:


Number Hardware Type (hrd)                          References
------ -----------------------------------          ----------
  [xx] IEEE 802.17                                  [RFC YYYY]

Note to the RFC Editor: Replace [xx] with the assigned value and [RFC YYYY] with the RFC number of this specification."

- I will advocate to delete Section 4.1.1. Its title is weird in a specification. The first paragraph does not fit here at all, because it has to be expanded in the IANA Considerations Section. The second paragraph provides some historical background, which once the document is published as an RFC, becomes irrelevant. So I suggest to delete the whole section 4.1.1.

Nits:


- Expand the first occurrence of every acronym, e.g., MPLS, IEEE, TTL, MAC, etc.

- Include a Table of Contents

- Avoid use of unnecessary future tense terms. For example, in Section 1, the draft says:

  "This document will describe all the necessary
  mappings to aid interoperable networks.  "

and should be written in present tense, e.g., "this document describes ..."

- Starting at Section 2.2.1, the draft uses square brackets to indicate protocol fields. These can be confused with references, which use also square brackets, so you may consider the use of some other symbol to denote protocol fields (example: ', ", -, (), etc.). So, the first line in Section 2.2.1 could be written as:

  The destination address (DA) (destination-address) is the ...

Also, I noticed that in other sections, such as 2.2.4, the protocol fields are enclosed in parenthesis (see last line of the first paragraph in Section 2.2.4), so both should use the same mechanism.

- Section 2.2.3, 2nd line:

  s/is it ability/is its ability

- Section 2.2.4, 3rd line:

  s/parameter indicate a request/parameter indicates a request

- Missing final dot in paragraphs in Sections 3.1.4. and 5.5. Also in the 2nd bullet point in Section 7.

- Section 4.2, under 3rd paragraph under Table 2.

  s/These guidleines/These guidelines/

[Ballot discuss]
(Based on Gen-ART review by Miguel Garcia)

Section 2 contains normative statements addressed to the reader,
rather than qualifying protocol features:

>  This section SHALL NOT be used as a definitive
>  description ...

and

>  IEEE 802.17 SHALL be consulted ...

Please reword to fit RFC 2119, for example:

"It is not the purpose of this section to become a replacement of the
normative IEEE 802.17 [2] or IEEE 802.17a [14] specifications."

and

"The reader is encouraged to consult IEEE 802.17 [2] and IEEE 802.17a
[14] for normative details of functionality."

or

"Implementation of the current specification MUST follow
  IEEE 802.17 [2] and IEEE 802.17a [14]."

(according to which of those you really mean).

- Section 3.3, last sentence of the section, contains some unclear
wording around the normative MAY. The text reads:

>    Note that a maximum jumbo frame payload size that MAY
>    be supported is defined at 9100 bytes.

This makes no sense as a normative statement. Why not just
change to lower case "may"?

References must be split into Normative/Informative sections.

[Ballot discuss]
(Based on Gen-ART review by Miguel Garcia)

Section 2 contains normative statements addressed to the reader,
rather than qualifying protocol features:

>  This section SHALL NOT be used as a definitive
>  description ...

and

>  IEEE 802.17 SHALL be consulted ...

Please reword to fit RFC 2119, for example:

"It is not the purpose of this section to become a replacement of the
normative IEEE 802.17 [2] or IEEE 802.17a [14] specifications."

and

"The reader is encouraged to consult IEEE 802.17 [2] and IEEE 802.17a
[14] for normative details of functionality."

or

"Implementation of the current specification MUST follow
  IEEE 802.17 [2] and IEEE 802.17a [14]."

(according to which of those you really mean).

- Section 3.3, last sentence of the section, contains some unclear
wording around the normative MAY. The text reads:

>    Note that a maximum jumbo frame payload size that MAY
>    be supported is defined at 9100 bytes.

This makes no sense as a normative statement. Why not just
change to lower case "may"?

PROTO Write-up

> 1. Have the chairs personally reviewed this version of the ID and
> do they believe this ID is sufficiently baked to forward to the IESG
> for publication?
>
> IPoRPR chairs have and support progression, I am still waiting for
> confirmation that the MPLS chairs have
> 2. Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the depth or
> breadth of the reviews that have been performed?
>
> I believe that all the relevant experts (in IEEE 802.17, IETF MPLS,
> TSVWG, etc.) have been consulted and have made comments, if necessary,
> on this draft
> 3. Do you have concerns that the document needs more review from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, etc.)?
>
> No
> 4. Do you have any specific concerns/issues with this document that
> you believe the ADs and/or IESG should be aware of? For example,
> perhaps you are uncomfortable with certain parts of the document, or
> whether there really is a need for it, etc., but at the same time
> these issues have been discussed in the WG and the WG has indicated it
> wishes to advance the document anyway.
>
> No.
> 5. 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?
>
> The WG is mostly silent, but there is support from the few active
> participants.
> 6. Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize what are they upset about.
>
> No
> 7. Have the chairs verified that the document adheres to _all_ of
> the ID nits? (see http://www.ietf.org/ID-nits.html).
>
> Yes.
> 8. Does the document a) split references into
> normative/informative, and b) are there normative references to IDs,
> where the IDs are not also ready for advancement or are otherwise in
> an unclear state? (Note: the RFC editor will not publish an RFC with
> normative references to IDs, it will delay publication until all such
> IDs are also ready for publication as RFCs.)
>
> A - No
> B - Yes, draft-ietf-tsvwg-diffserv-class-aggr has not completed WG
> last call at this point, but is expected to shortly.
> 9. For Standards Track and BCP documents, the IESG approval
> announcement includes a write-up section with the following sections:
> * Technical Summary
> This document specifies a basic method of
> encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17
> Resilient packet ring (RPR) datagrams. 'Basic' means that the higher
> layers treat RPR as a broadcast media (future encapsulations may
> specify how to control RPR). As a result, the mapping is
> straightforward -- the majority of the detail is focused on showing a
> default mapping between IP & MPLS service classes and RPR service
> classes.
> * Working Group Summary
> The IPoRPR & MPLS working groups had consensus
> to publish this document.
> * Protocol Quality
> This mapping is already generally in use.
> However, the publication of this standard will rally the community to
> a single default service class mapping to improve interoperability.
>

-------- Original Message --------
Subject: RE: iporpr documents
Date: Wed, 3 May 2006 03:42:45 -0400
From: Glenn Parsons
To: Mark Townsley


Mark,

Thanks for the reminder.

We have been a bit lax since Vancouver since it was pointed out a couple
of the drafts we were referencing had not stabilized.  Now that they are
and we have IEEE 802.17 comments, we need to update the draft and then
proceed with the joint IPoRPR/MPLS WG last call.

I hope to get this done by the end of the month.

Cheers,
Glenn.