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. > 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-extension > >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
