Skip to main content

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

Discuss


Yes

(Jari Arkko)
(Mark Townsley)

No Objection

(Cullen Jennings)
(David Kessens)
(Lisa Dusseault)
(Magnus Westerlund)
(Ross Callon)
(Ted Hardie)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Bill Fenner Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2006-11-16) Unknown
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.
Brian Carpenter Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2006-11-13) Unknown
(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.
Dan Romascanu Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2006-11-13) Unknown
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
Russ Housley Former IESG member
(was No Objection) Discuss
Discuss [Treat as non-blocking comment] (2007-10-25) Unknown
(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.
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown