Shenshen, Thanks for your reply. Fixed the typos.
Jensen On Fri, Jun 30, 2017 at 9:20 PM Shenshen Chen <[email protected]> wrote: > Hi all, > > I'd like to join this discussion. > > About the flow-cost-confidences, I prefer the original design. > The mean of cost makes sense (the expected cost if pick path randomly) > and can't be deduced from the range (since it may not be an > equal probability distribution). > > > Here is a list of typos (comments are marked with ">>>"): > > [Page 1] > 3.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 4 > 3.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 4 > 3.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 5 > > >>> Accept => Acceptable, also see 3.3.2. and 4.2.3. > > [Page 1] > 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > >>> Example => Examples > > >>> Also, the catalog doesn't include Section 4.2.5.1., 4.2.6.1., etc, > which looks weird. > > [Page 1] > The emergence of new networking datapath capabilities has > substantially increased the flexibility of networking. For example, > OpenFlow has emerged as a major southbound protocol for Software- > Defined Networking, and OpenFlow allows flexible routing beyond > simple destination-based routing. In this document, we define a new > extention to ALTO, namely the Flow Cost Service, for ALTO clients in > > >>> extention => extension > > an OpenFlow-enabled network to query ALTO network information. > > [Page 6] > The Protocol field is REQUIRED. The available values contain > different protocols including layer two protocols (e.g. "eth") and > layer three protocols (e.g. "ipv4", "ipv6"). It can also be > specified upper-layer protocols (e.g. "udp", "tcp", "ssh", "http" and > "ftp"). The source and destination protocols MUST NOT be conflict. > > >>> be conflict => be conflicted > > In every EndpointFilter object of either "endpoints" field or > "endpoint-flows" field, if the source protocol is conflict with the > > >>> is conflict with => has conflict with > > destination protocol, this endpoint pair is invalid. For different > protocols, some additional constraints are defined in Section 3.2.3. > > [Page 7] > protocols: Defines a list of JSONString indicating the supported > Protocol values of the EndpointURI in the request. The ALTO > server does not have to claim "ipv4" and "ipv6" in this field > explictly, because they are supported by default. If not present, > > >>> explictly => explicitly > > this field MUST be interpreted as if it is specified the default > supported protocols "ipv4" and "ipv6". > > [Page 16] > The ALTO servers can provide more information to the clients when > requests have errors. The FlowCostErrorMap below can provide basic > information about two most common errors for the flow cost service. > The ALTO servers MAY include it as the data component of an ALTO > error response. If multiple errors are identified, the ALTO server > MUST return exactly one error code according to Section 8.5.2 of > [RFC7285] . > > [Page 20] > Security considerations: Security considerations are identical to > those specified in Section 15 of [RFC7285] . > > >>> remove the redundent space between [RFC7285] and full stop > > [Page 16, 17] > Some header fields may have conflicts. For example, IPv4 fields and > IPv6 fields can never appear in the same packet, nor can TCP and UDP > ports. These header fields MUST not be included in the same flow > filter, otherwise the ALTO server MUST return an ALTO error response, > with the error code "E_INVALID_FIELD_VALUE". As specified in > > >>> , otherwise => . Otherwise, > remove the comma before "with" > > Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field" > and the "value" in the "meta" field. In this case, the ALTO server > MUST use the flow ID as the "field" and the flow filter as the > "value". However, the recommended approach is to use the > FlowCostErrorMap, where the server CAN provide the conflicting typed > header fields in the "conflicts" field of the FlowFilterError > associated with the corresponding flow ID. > > Best Regards, > Shenshen > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
