Hi Peter, Thank you for the changes, I cleared my DISCUSS. Best Regards, Alexey
On Thu, Dec 14, 2017, at 12:37 PM, Peter Psenak wrote: > Hi Alexey, > > thanks for your comments. I have addressed them all except the one on > the byte ordering, because as Acee has mentioned already all encodings > are always in Network-Byte order. > > Please see the updated version at: > https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt > > > thanks, > Peter > > On 13/12/17 11:47 , Alexey Melnikov 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-extensions/ > > > > > > > > ---------------------------------------------------------------------- > > 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 [email protected] https://www.ietf.org/mailman/listinfo/ospf
