On 12/14/17, 7:59 AM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote:
>On Wed, Dec 13, 2017, at 07:52 PM, Acee Lindem (acee) wrote: >> Hi Alexey >> >> These all seem to be valid comments except for the one on byte order. >> Note >> that section 3.1 of RFC 2360 already states that IETF document packet >> encodings are in Network-Byte Order (NBO). >> https://www.ietf.org/rfc/rfc2360.txt > >Well, lots of recent RFCs violate this, so repeating it doesn't hurt. Can you provide an example? IETF standard packets should always be in Network-Byte Order. Thanks, Acee > >> Typically, we have not defined Reserved field usage. However, I guess we >> could say that they SHOULD be set to 0 on transmission and MUST be >> ignored >> on reception. > >Yes, please. Just mention it once early in the document. > >> This will allow for future reuse in a backward compatible >> manner. >> Thanks, >> Acee >> >> >> >> >> >> On 12/13/17, 5:47 AM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote: >> >> >Alexey Melnikov has entered the following ballot position for >> >draft-ietf-ospf-segment-routing-extensions-23: Discuss >> > >> >When responding, please keep the subject line intact and reply to all >> >email addresses included in the To and CC lines. (Feel free to cut this >> >introductory paragraph, however.) >> > >> > >> >Please refer to >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> >for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> >The document, along with other ballot positions, can be found here: >> >>>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensi >>>on >> >s/ >> > >> > >> > >> >---------------------------------------------------------------------- >> >DISCUSS: >> >---------------------------------------------------------------------- >> > >> >This is generally a clearly written document, but it needs a few minor >> >changes >> >before I can recommend its approval for publication. >> > >> >1) In Section 3.2: >> > >> > o When a router receives multiple overlapping ranges, it MUST >> > conform to the procedures defined in >> > [I-D.ietf-spring-conflict-resolution]. >> > >> >RFC 2119 keyword usage makes the reference a Normative reference, yet >>it >> >is >> >currently listed as informative. >> > >> >3.4. SRMS Preference TLV >> > >> > The Segment Routing Mapping Server Preference TLV (SRMS Preference >> > TLV) is used to advertise a preference associated with the node that >> > acts as an SR Mapping Server. The role of an SRMS is described in >> > [I-D.ietf-spring-segment-routing-ldp-interop]. >> > >> >As draff-ietf-spring-segment-routing-ldp-interop needs to be read in >> >order to >> >understand what SR Mapping Server is, this reference must also be >> >Normative. >> > >> > SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. >> > >> >This just confirms that this reference must be Normative. >> > >> >2) In Section 3.1: >> > >> > When multiple SR-Algorithm TLVs are received from a given router, >>the >> > receiver SHOULD use the first occurrence of the TLV in the Router >> > Information LSA. If the SR-Algorithm TLV appears in multiple Router >> > Information LSAs that have different flooding scopes, the SR- >> > Algorithm TLV in the Router Information LSA with the area-scoped >> > flooding scope SHOULD be used. If the SR-Algorithm TLV appears in >> > multiple Router Information LSAs that have the same flooding scope, >> > the SR-Algorithm TLV in the Router Information (RI) LSA with the >> > numerically smallest Instance ID SHOULD be used and subsequent >> > instances of the SR-Algorithm TLV SHOULD be ignored. >> > >> >In the last 2 sentences: why are you using SHOULD (twice) instead of >> >MUST? This >> >seems to affect interoperability. >> > >> >(I think there is similar text in another section.) >> > >> > >> >---------------------------------------------------------------------- >> >COMMENT: >> >---------------------------------------------------------------------- >> > >> >Several TLVs have "Reserved" fields, yet you never explain what >>"Reserved" >> >means. You do explain what reserved flags mean in some of them. I >>suggest >> >either explicitly explaining what Reserved means in each case or >>specify >> >this >> >in the terminology section near the beginning of the document. >> > >> >The document never specifies byte order for length fields. >> > >> >The acronym NSSA is never explained and it has no reference. >> > >> > >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf