Subject: [forces] FW: [IANA #654410] Last Call: <draft-ietf-forces-lfb-lib-10.txt> (ForCES Logical Function Block (LFB) Library) to Proposed Standard

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Feb 2013 16:48:36 -0000

Authors,

IANA need an answer from you.
Let me know if your discussions result in the need to update the document.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Pearl
> Liang via RT
> Sent: 08 February 2013 16:40
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [IANA #654410] Last Call: <draft-ietf-forces-lfb-lib-10.txt> (ForCES Logical
> Function Block (LFB) Library) to Proposed Standard
> 
> (BEGIN IANA LAST CALL COMMENTS)
> 
> IESG:
> 
> IANA has reviewed draft-ietf-forces-lfb-lib-10 and has the following
> comments:
> 
> We have questions about the IANA actions requested in this document.
> 
> We understand that, upon approval of this document, there are four
> actions which we must complete.
> 
> First in the Logical Functional Block (LFB) Class Names and Class Identifiers
> subregistry of the Forwarding and Control Element Separation (ForCES) registry
> located at:
> 
> www.iana.org/assignments/forces/forces.xml
> 
> fifteen (15) new entries are to be added to the registry as follows:
> 
> +-----------+---------------+------------------------+--------------+
> | LFB Class | LFB Class Name|     Description        |  Reference   |
> | Identifier|               |                        |              |
> +-----------+---------------+------------------------+--------------+
> |     3     |  EtherPHYCop  | Define an Ethernet port|[ RFC-to-be ] |
> |           |               | abstracted at physical |              |
> |           |               | layer.                 | Section 5.1.1|
> |           |               |                        |              |
> |     4     |  EtherMACIn   | Define an Ethernet     |[ RFC-to-be ] |
> |           |               | input port at MAC data | Section 5.1.2|
> |           |               | link layer.            |              |
> |           |               |                        |              |
> |     5     |EtherClassifier| Define the process to  |[ RFC-to-be ] |
> |           |               | decapsulate Ethernet   | Section 5.1.3|
> |           |               | packets and classify   |              |
> |           |               | the packets.           |              |
> |           |               |                        |              |
> |     6     |  EtherEncap   | Define the process to  |[ RFC-to-be ] |
> |           |               | encapsulate IP packets | Section 5.1.4|
> |           |               | to Ethernet packets.   |              |
> |           |               |                        |              |
> |     7     |  EtherMACOut  | Define an Ethernet     |[ RFC-to-be ] |
> |           |               | output port at MAC     | Section 5.1.5|
> |           |               | data link layer.       |              |
> |           |               |                        |              |
> |     8     | IPv4Validator | Perform IPv4 packets   |[ RFC-to-be ] |
> |           |               | validation.            | Section 5.2.1|
> |           |               |                        |              |
> |     9     | IPv6Validator | Perform IPv6 packets   |[ RFC-to-be ] |
> |           |               | validation.            | Section 5.2.2|
> |           |               |                        |              |
> |     10    | IPv4UcastLPM  | Perform IPv4 Longest   |[ RFC-to-be ] |
> |           |               | Prefix Match Lookup.   | Section 5.3.1|
> |           |               |                        |              |
> |     11    | IPv6UcastLPM  | Perform IPv6 Longest   |[ RFC-to-be ] |
> |           |               | Prefix Match Lookup.   | Section 5.3.3|
> |           |               |                        |              |
> |     12    |  IPv4NextHop  | Define the process of  |[ RFC-to-be ] |
> |           |               | selecting Ipv4 next hop| Section 5.3.2|
> |           |               | action.                |              |
> |           |               |                        |              |
> |     13    |  IPv6NextHop  | Define the process of  |[ RFC-to-be ] |
> |           |               | selecting Ipv6 next hop| Section 5.3.4|
> |           |               | action.                |              |
> |           |               |                        |              |
> |     14    |  RedirectIn   | Define the process for |[ RFC-to-be ] |
> |           |               | CE to inject data      | Section 5.4.1|
> |           |               | packets into FE LFB    |              |
> |           |               | topology.              |              |
> |           |               |                        |              |
> |     15    |  RedirectOut  | Define the process for |[ RFC-to-be ] |
> |           |               | LFBs in FE to deliver  | Section 5.4.2|
> |           |               | data packets to CE.    |              |
> |           |               |                        |              |
> |     16    | BasicMetadata | Dispatch input packets |[ RFC-to-be ] |
> |           |    Dispatch   | to a group output      | Section 5.5.1|
> |           |               | according to a metadata|              |
> |           |               |                        |              |
> |     17    |    Generic    | Define a preliminary   |[ RFC-to-be ] |
> |           |   Scheduler   | generic scheduling     | Section 5.5.2|
> |           |               | process.               |              |
> +-----------+---------------+------------------------+--------------+
> 
> Second, a new registry called the "Metadata ID Namespace" is to be created in
> the Forwarding and Control Element Separation (ForCES) registry located at:
> 
> www.iana.org/assignments/forces/forces.xml
> 
> Metadata ID values are 32 bits long.
> 
> The rules for registration in this subregistry are:
> 
> For Metadata ID values 0x00000000-0x7FFFFFFF maintenance is done through
> Specification Required as defined by RFC 5226.
> 
> The authors request that for Metadata ID values 0x80000000-0xFFFFFFFF:
> "Metadata IDs in this range are reserved for vendor private extensions and are
> the responsibility of individuals."
> 
> Question - Do the authors mean that this range is maintained via Private Use as
> defined in RFC 5226?
> 
> There are initial registrations in this subregistry as follows:
> 
> +--------------+-------------------------+--------------------------+
> |   Value      |           Name          |        Reference         |
> +--------------+-------------------------+--------------------------+
> |  0x00000001  |       PHYPortID         |      [ RFC-to-be ]       |
> |  0x00000002  |         SrcMAC          |      [ RFC-to-be ]       |
> |  0x00000003  |         DstMAC          |      [ RFC-to-be ]       |
> |  0x00000004  |       LogicalPortID     |      [ RFC-to-be ]       |
> |  0x00000005  |         EtherType       |      [ RFC-to-be ]       |
> |  0x00000006  |          VlanID         |      [ RFC-to-be ]       |
> |  0x00000007  |       VlanPriority      |      [ RFC-to-be ]       |
> |  0x00000008  |       NextHopIPv4Addr   |      [ RFC-to-be ]       |
> |  0x00000009  |       NextHopIPv6Addr   |      [ RFC-to-be ]       |
> |  0x0000000A  |       HopSelector       |      [ RFC-to-be ]       |
> |  0x0000000B  |       ExceptionID       |      [ RFC-to-be ]       |
> |  0x0000000C  |      ValidateErrorID    |      [ RFC-to-be ]       |
> |  0x0000000D  |         L3PortID        |      [ RFC-to-be ]       |
> |  0x0000000E  |       RedirectIndex     |      [ RFC-to-be ]       |
> |  0x0000000F  |    MediaEncapInfoIndex  |      [ RFC-to-be ]       |
> +--------------+-------------------------+--------------------------+
> 
> 
> Third, a new registry called the "Exception ID Namespace" is to be created in the
> Forwarding and Control Element Separation (ForCES) registry located at:
> 
> www.iana.org/assignments/forces/forces.xml
> 
> Exception ID values are 32 bits long.
> 
> The rules for registration in this subregistry are:
> 
> For Exception ID values 0x00000000-0x7FFFFFFF maintenance is done through
> Specification Required as defined by RFC 5226.
> 
> The authors request that for Exception ID values 0x80000000-0xFFFFFFFF:
> "Exception IDs in this range are reserved for vendor private extensions and are
> the responsibility of individuals."
> 
> Question - Do the authors mean that this range is maintained via Private Use as
> defined in RFC 5226?
> 
> There are initial registrations in this subregistry as follows:
> 
> +--------------+---------------------------------+------------------+
> |   Value      |           Name                  |   Reference      |
> +--------------+---------------------------------+------------------+
> |  0x00000000  |  AnyUnrecognizedExceptionCase   |  [ RFC-to-be ]   |
> |  0x00000001  |        ClassifyNoMatching       |  [ RFC-to-be ]   |
> |  0x00000002  |   MediaEncapInfoIndexInvalid    |  [ RFC-to-be ]   |
> |  0x00000003  |       EncapTableLookupFailed    |  [ RFC-to-be ]   |
> |  0x00000004  |             BadTTL              |  [ RFC-to-be ]   |
> |  0x00000005  |     IPv4HeaderLengthMismatch    |  [ RFC-to-be ]   |
> |  0x00000006  |        RouterAlertOptions       |  [ RFC-to-be ]   |
> |  0x00000007  |         IPv6HopLimitZero        |  [ RFC-to-be ]   |
> |  0x00000008  |       IPv6NextHeaderHBH         |  [ RFC-to-be ]   |
> |  0x00000009  |      SrcAddressExecption        |  [ RFC-to-be ]   |
> |  0x0000000A  |      DstAddressExecption        |  [ RFC-to-be ]   |
> |  0x0000000B  |        LPMLookupFailed          |  [ RFC-to-be ]   |
> |  0x0000000C  |       HopSelectorInvalid        |  [ RFC-to-be ]   |
> |  0x0000000D  |      NextHopLookupFailed        |  [ RFC-to-be ]   |
> |  0x0000000E  |          FragRequired           |  [ RFC-to-be ]   |
> |  0x0000000F  |       MetadataNoMatching        |  [ RFC-to-be ]   |
> +--------------+---------------------------------+------------------+
> 
> Fourth, a new registry called the "Validate Error ID Namespace" is to be created in
> the Forwarding and Control Element Separation (ForCES) registry located at:
> 
> www.iana.org/assignments/forces/forces.xml
> 
> Validate Error ID values are 32 bits long.
> 
> The rules for registration in this subregistry are:
> 
> For Validate Error ID values 0x00000000-0x7FFFFFFF maintenance is done
> through Specification Required as defined by RFC 5226.
> 
> The authors request that for Validate Error ID values 0x80000000-0xFFFFFFFF:
> "Validate Error IDs in this range are reserved for vendor private extensions and
> are the responsibility of individuals."
> 
> Question - Do the authors mean that this range is maintained via Private Use as
> defined in RFC 5226?
> 
> There are initial registrations in this subregistry as follows:
> 
> +--------------+---------------------------------+------------------+
> |   Value      |           Name                  |   Definition     |
> +--------------+---------------------------------+------------------+
> |  0x00000000  | AnyUnrecognizedValidateErrorCase| [ RFC-to-be ]    |
> |  0x00000001  |        InvalidIPv4PacketSize    | [ RFC-to-be ]    |
> |  0x00000002  |           NotIPv4Packet         | [ RFC-to-be ]    |
> |  0x00000003  |    InvalidIPv4HeaderLengthSize  | [ RFC-to-be ]    |
> |  0x00000004  |    InvalidIPv4LengthFieldSize   | [ RFC-to-be ]    |
> |  0x00000005  |         InvalidIPv4Checksum     | [ RFC-to-be ]    |
> |  0x00000006  |      InvalidIPv4SrcAddr         | [ RFC-to-be ]    |
> |  0x00000007  |      InvalidIPv4DstAddr         | [ RFC-to-be ]    |
> |  0x00000008  |      InvalidIPv6PakcetSize      | [ RFC-to-be ]    |
> |  0x00000009  |          NotIPv6Packet          | [ RFC-to-be ]    |
> |  0x0000000A  |      InvalidIPv6SrcAddr         | [ RFC-to-be ]    |
> |  0x0000000B  |      InvalidIPv6DstAddr         | [ RFC-to-be ]    |
> +--------------+---------------------------------+------------------+
> 
> We understand that these four actions are the only ones required to be
> completed upon approval of this document.
> 
> Note:  The actions requested in this document will not be completed
> until the document has been approved for publication as an RFC.
> This message is only to confirm what actions will be performed.
> 
> Thanks,
> 
> Pearl Liang
> ICANN/IANA
> 
> (END IANA LAST CALL COMMENTS)
> 
> 
> On Mon Jan 28 12:03:42 2013, [email-masked] wrote:
> >
> > The IESG has received a request from the Forwarding and Control Element
> > Separation WG (forces) to consider the following document:
> > - 'ForCES Logical Function Block (LFB) Library'
> >   <draft-ietf-forces-lfb-lib-10.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > [email-masked] mailing lists by 2013-02-11. Exceptionally, comments may be
> > sent to [email-masked] instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >    This document defines basic classes of Logical Function Blocks (LFBs)
> >    used in the Forwarding and Control Element Separation (ForCES).  The
> >    basic LFB classes are defined according to ForCES FE model and ForCES
> >    protocol specifications, and are scoped to meet requirements of
> >    typical router functions and considered as the basic LFB library for
> >    ForCES.  The library includes the descriptions of the LFBs and the
> >    XML definitions.
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 9 Feb 2013 10:50:49 +0800

I'm quite sure that all the spaces mentioned as 'range reserved for vendor private extensions and are the responsibility of individuals' are intended for Private Local Use only and should not attemping FCFS. 

I'm not sure if the 'Specification Required' include a FCFS service? if not, we may open a space specifically for FCFS registry service. 

thanks,
Weiming

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, February 09, 2013 12:48 AM
Subject: [forces] FW: [IANA #654410] Last Call:<draft-ietf-forces-lfb-lib-10.txt> (ForCES Logical FunctionBlock (LFB) Library) to Proposed Standard

> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Joel <[email-masked]>
Date: Fri, 08 Feb 2013 22:20:47 -0500

Specification Required means that you have to provide a spec, but if you 
do it is FCFS.  Pure FCFS means that you simply request a number and you 
get one.
It is quite reasonable to take the view that anything registered should 
have a spec.  I just wanted to makesure that was really the WG agreemet.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 10 Feb 2013 11:43:11 -0500

On Fri, Feb 8, 2013 at 10:20 PM, Joel <[email-masked]> wrote:
> Specification Required means that you have to provide a spec, but if you do
> it is FCFS.  Pure FCFS means that you simply request a number and you get
> one.
> It is quite reasonable to take the view that anything registered should have
> a spec.  I just wanted to make sure that was really the WG agreemet.
>

Nod (as in positive ACK) from here.

cheers,
jamal