Subject: [RTG-DIR] RtgDir review: draft-ietf-lisp-ddt-07.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 2 Aug 2016 11:06:07 +0100

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-lisp-ddt-07.txt
Reviewer: Ben Niven-Jenkins
Review Date: 2nd August 2016
Intended Status: Experimental

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
I found the document to be easily readable even though I am not well versed in LISP.

Minor issues:
1) The document appears quite light on RFC2119 language (MUST/SHOULD). There are probably areas of the protocol specification that may benefit from more use of RFC2119 language.

To give one example: Section 7.3.2 says "this Map-Reply will indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist and will have a TTL value of 15 minutes.” is that really a “SHOULD [or MUST?] have a TTL value of 15 minutes”? 

2) In a few places the document refers to a “proxy Map-Reply service” without really explaining what it is. A description in the terminology section would help, or a reference to another document that defines the term.

HTH
Ben

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Aug 2016 13:27:11 -0400

Thank you Ben.
These appear to be two quite sensible concerns.
I will let the the authors reply to both, but I have a request on the 
first comment.
Could you send the authors a list of those places you noticed where you 
expected to see 2119 language?  While I am confident they will take 
another look at the issue, a few pointers would increase their efficacy.

Yours,
Joel

On 8/2/16 6:06 AM, Ben Niven-Jenkins wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review
> is to provide assistance to the Routing ADs. For more information
> about the Routing Directorate, please see ​
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-lisp-ddt-07.txt Reviewer: Ben Niven-Jenkins
> Review Date: 2nd August 2016 Intended Status: Experimental
>
>
> Summary: I have some minor concerns about this document that I think
> should be resolved before publication.
>
> Comments: I found the document to be easily readable even though I am
> not well versed in LISP.
>
> Minor issues: 1) The document appears quite light on RFC2119 language
> (MUST/SHOULD). There are probably areas of the protocol specification
> that may benefit from more use of RFC2119 language.
>
> To give one example: Section 7.3.2 says "this Map-Reply will indicate
> the least-specific XEID-prefix matching the requested XEID for which
> no delegations exist and will have a TTL value of 15 minutes.” is
> that really a “SHOULD [or MUST?] have a TTL value of 15 minutes”?
>
> 2) In a few places the document refers to a “proxy Map-Reply service”
> without really explaining what it is. A description in the
> terminology section would help, or a reference to another document
> that defines the term.
>
>
> HTH Ben
>
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 12 Aug 2016 11:26:23 +0100

Joel, Authors,

Sorry for the late reply. I will try and take another pass over the document this week and list the places I think 2119 language may be expected.

Ben

> On 2 Aug 2016, at 18:27, Joel M. Halpern <[email-masked]> wrote:
> 
> Thank you Ben.
> I will let the the authors reply to both, but I have a request on the first comment.
> Could you send the authors a list of those places you noticed where you expected to see 2119 language?  While I am confident they will take another look at the issue, a few pointers would increase their efficacy.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Aug 2016 09:47:44 -0400

Thank you Ben.

> Sorry for the late reply. I will try and take another pass over the document this week and list the places I think 2119 language may be expected.
...

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 15 Aug 2016 12:50:04 +0100

Authors,

See below for a list of places in draft-ietf-lisp-ddt-07 that I noted down which might benefit from using RFC2119 language. I don’t have the cycles to discuss them individually so I leave it to your discretion as to which ones may or may not make sense to incorporate in the document.

Section 4.2.1: “A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node.” is this really something like “Map-Requests received by DDT nodes that do not match a configured XEID-prefix MUST/SHOULD be referred to the root node”?

Section 4.2.1: “The root node in a particular instantiation of LISP-DDT must therefore be configured with delegations for at least all defined IIDs and AFIs.” Should the must be a MUST?

Section 6.2: “For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a DDT node includes in the Map-Referral message a list of RLOCs for all DDT nodes that are authoritative for the XEID-prefix being returned;” Should this be “a DDT node MUST/SHOULD include in the Map-Referral…”

Section 6.3 “A DDT node must set the "incomplete" flag in the following cases:” Should the must be a MUST?

Section 6.4 (under table): “It is set when the Map Server has not encoded the Map Server set information.” Should this be “It MUST be set”?

Section 6.4: “The number of sig sections at the end of the Record must match the SigCnt.” Should the must be a MUST?

Section 6.4: “Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the record.” Should this be “keys MUST NOT be included in the record”?

Section 6.4.1: “If SigCnt field in the Map-Referral is not 0, the signature information is included at the end of captured in a sig section as described below.” Should this be “signature information MUST be included…”

Section 6.4.1: “Reserved: This field must be set to 0 on transmit and must be ignored on receipt.” Should the two instances of must be MUST?

Section 7.1.1: “If the delegation is known to be a DDT Map Server, then the Map-Referral message is sent with action code MS-REFERRAL to indicate…” Should this be “the Map-Referral message MUST be sent with action code…”?

Section 7.1.1: “…to the receiver that LISP-SEC information (if saved in the pending request) should be included in the next DDT Map-Request;” Is the “should be included” really a SHOULD/MUST be included?

Section 7.1.1: “otherwise, the action code NODE-REFERRAL is used.” Should this be “MUST be used”?

Section 7.1.2: “If the requested XEID did not match a configured delegation but does match an authoritative XEID-prefix, then the DDT node returns a negative Map-Referral” Should this be “The DDT node MUST return a negative Map-Referral”?

Section 7.1.2: “The action code is set to DELEGATION-HOLE” Should this be “MUST be set to”?

Section 7.1.2: “If the requested XEID did not match either a configured delegation or an authoritative XEID-prefix, then the request is dropped and a negative Map-Referral with action code NOT-AUTHORITATIVE is returned.” Should this be “the request MUST be dropped and a negative Map-Referral with action code NOT-AUTHORITATIVE MUST be returned.”?

Section 7.2: “and a Map-Referral with the MS-ACK action is returned to the sender of the DDT Map-Request.” Should this be “MUST be returned”?

Section 7.2: “then a negative Map-Referral with action code MS-NOT-REGISTERED is returned to the sender of the DDT Map-Request.” Should this be “MUST be returned”?

Section 7.3.1: “a negative Map-Reply is returned and no further processing is performed by the DDT Map Resolver.” Should this be “MUST be returned”?

Section 7.3.1: “If a Map Resolver does not have such configuration, it will return a Negative Map-Reply if it receives a query for an EID outside the subset of the mapping database known to it.” Should this be “it MUST return”?

Section 7.3.2 “If the maximum number of retransmissions has occurred and all RLOCs have been tried, then the pending request list entry is dequeued.” I am not entirely sure what dequeuing an entry means. It feels like there may be something missing, e.g. what response the Map Resolver is expected to (SHOULD/MUST?) send to the client that made the original request? 

Section 7.3.2 NODE-REFERRAL: “security information saved with the original Map-Request is not included.” Should this be “MUST NOT be included”?

Section 7.3.2 MS-REFERRAL: “except that that security information saved with the original Map-Request is included in the new Map-Request sent to a Map Server” Should this be “MUST be included”? (Nit: s/that that/that/)

Section 7.3.2 MS-ACK: “then the pending request for the XEID is complete and is dequeued.” Same as above, I am not entirely sure what dequeuing an entry means. It feels like there may be something missing, e.g. what response the Map Resolver is expected to (SHOULD/MUST?) send to the client that made the original request?

Section 7.3.2 MS-ACK: “the DDT Map Resolver re-sends the DDT Map-Request with LISP-SEC information included and the pending request queue entry remains until another Map-Referral with MS-ACK action code is received.” Should this be “Map Resolver MUST resend”? What is the expected behaviour of the Map Resolver when the 2nd Map-Referral with MS-ACK is received? What is the expected behaviour if the 2nd Map-Referral is not received?

Section 7.3.2 MS-NOT-REGISTERED: “The DDT Map Resolver returns a negative Map-Reply to the original Map-Request sender; this Map-Reply contains the non-registered XEID-prefix with TTL value of one minute.” Should this be “MUST return” and “SHOULD [or MUST] contain”?  The behaviour described here is what feels like it could be missing from the examples above that reference dequeuing.

Section 7.3.2 DELEGATION-HOLE: “The DDT Map Resolver returns a negative Map-Reply to the original Map-Request sender” Should this be “MUST return”?

Section 7.3.2 DELEGATION-HOLE: "this Map-Reply will indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist and will have a TTL value of 15 minutes.” is that really a “SHOULD [or MUST?] have a TTL value of 15 minutes”?

Section 7.3.2 NOT-AUTHORITATIVE “The pending request list entry that caused this answer is removed, with no answer returned to the original requestor.” “no answer returned” feels a bit loose. Maybe more specific about the behaviour expected. E.g. I interpret it to mean “send no response and the client is left hanging until it times out the request”, is that what is expected?

Section 10.1: “Every signed Map-Referral also includes the public keys associated with each child DDT node.” Should that be “MUST include”?

Section 10.2: “A revocation record must be advertised for a period of time equal to or greater than the TTL value of the Record that initially advertised the key” Should the “must” be a “MUST”?

Section 10.4: Contains several instances of “must”. I wonder if they should really be “MUST”s?

HTH
Ben

> On 12 Aug 2016, at 11:26, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Joel, Authors,
>