Subject: Re: [Dime] DOIC WGLC: Editorial Comments

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 2 Jan 2015 11:36:22 +0000

-- 4.1.3, para 9: "ambiguity"

I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"? 

SRD> The point is that the reacting nodes and reporting nodes must
unambiguously know what to do.  I think ambiguous is the right word

Ben> I can construct behavior that is not ambiguous to upstream or downstream nodes, but still breaks normative requirements. How about " ... ensure that it does not introduce incorrect behavior for either the upstream or downstream DOIC nodes."

JJ> as Ben, ambiguity is not so right. 
A proposal: "When making changes to the OC-Supported-Features or OC-OLR AVPs, the Diameter Agent needs to ensure  consistency in its behavior with both upstream and downstream DOIC nodes".

Ulrich> I agree with SRD. The ambiguity (in DOIC behavior for e.g. a reacting node) that needs to be avoided may result from an agent on path1 between client and server that makes changes to OC-Supported-Features within answers while other agents on other paths between client and server make no or different changes. The reacting node (client) would get mixed signals depending on the path taken, resulting in ambiguity.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 05 Jan 2015 09:04:28 -0600

I'm ok with unambiguous, ensuring consistency or not incorrect.

I'm inclined to go with JJ's wording.

Steve

On 1/2/15 5:36 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 5 Jan 2015 17:12:16 -0600

> On Dec 29, 2014, at 10:38 AM, Steve Donovan <[email-masked]> wrote:
> 
> 
> On 12/22/14 6:11 PM, Ben Campbell wrote:
>> Hi, I've removed sections that seem to need no further discussion, where you've suggested moving to separate threads, or where I'm just gonna roll over :-)
>> 
>>> On Dec 22, 2014, at 10:56 AM, Steve Donovan <[email-masked]> wrote:
>> [...]
>>>>>> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>>>>>> 
>>>>>> This is also true if it needs to announce some other feature that needs to be indicated.
>>>>> SRD> This paragraph is talking specifically about algorithms and is needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.
>>>> We say this in 4.1.1 on reacting node behavior. We should make the same statement for reporting node behavior. This is the definitive section on reporting node behavior. If it's repeated elsewhere, we should consider whether _that_ text is redundant.
>>> SRD> Again, this paragraph is dealing specifically with rules around which the algorithms supported by the reporting node interact with the OC-Features-Vector AVP.  The statement on other features is three paragraphs later.
>> If you mean this paragraph:
>> 
>> "  The reporting node SHOULD indicate support for other DOIC features
>>    defined in extension drafts that it supports and that apply to the
>>    transaction."
>> 
>> Nothing in that (3 paragraphs later) paragraph says you MUST include OC-Features-Vector to do that. It's left for the reader to infer. We do explicitly say that for reacting nodes in 4.1.1.
> SRD>  How about adding ..."it does so using the OC-Feature-Vector AVP" to the end of the above paragraph.

That would work for me.

>> [...]

---

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 10:33:48 -0600

On 12/22/14 2:24 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
>
> Hereafter some comments (with JJ>)on some of the points discussed between Ben and Steve. They are not essential
>   
>
> -- section 3.1, 3rd paragraph: "Reporting nodes also include overload reports..."
>
> "Reporting nodes _may_ also include overload reports..."
> JJ> The "may" is ambiguous as there is a SHOULD in 4.2.3 when an active OCS. For my clarification, has a "may" in lower case a different meaning from a MAY in upper case. To be only descriptive as with 1st sentence of the paragraph : eg " Reporting nodes communicate overload occurrences by sending the OLR AVP in answers (coming from 3.4, para 4".
>
>   [...]
SRD> "may" in lower case is not a normative requirement.
>
> -- section 3.3, general:
>
> Much of this section is redundant to stuff in the parent section. (**JJ section 3)I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.) (**JJ effectively, but may need significant modifications )
> SRD> Do you have specific suggestions?
> Ben> Remove the 2nd to last and 3rd to last paragraph in 3.0.
> JJ> OK but in 3.3 to use the text of the removed paragraphs from 3.0 for host report as well as for realm report
SRD> Ok.
> A proposal: "When making changes to the OC-Supported-Features or OC-OLR AVPs, the Diameter Agent needs to ensure  consistency in its behavior with both upstream and downstream DOIC nodes".
SRD> Addressed in a separate message.
> 	
>
> -- 4.2.1.1, para 1:
>
> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
> SRD> Do you have suggested wording?
> Ben> It depends. Does a reacting node keep OCS when it hasn't received an OLR?
>
> If no:
>
> "A reacting node SHOULD maintain the following OCS for each active OLR it receives per Diameter application..."
>
> if yes:
>
> Then I think the section needs some more thought to distinguish between what is stored for OLRs, vs when no OLR is received.
>
> Also, I think the preface to the second bullet list seems wrong. I don't see how you could make an implementation work right without at least keeping sequence number and expiration time, at least when you have an active OLR.
>
> JJ>  my point would be to describe in 4.2.1.3 when an OCS is created / deleted (as in 4.2.1.4 for Reporting node which addresses the creation of an OCS, deletion should also be added))
> About the MAY in the preface to the second bullet list, to a have a SHOULD in line with 1st paragraph statement "the A reacting node SHOULD maintain the following OCS..." As it is implementation, there were remarks that various ways can  address the OCS or equivalent  handling
SRD> The following is already in 4.2.1.3 (now 5.2.1.3 in -06):

    If the received OLR is for a new overload condition then a reacting
    node MUST generate a new OCS entry for the overload condition.

>
> [...]
>
> -- 4.2.1.3, para 2:
>
> Should this combination include origin-host or origin-realm? App-Id?
> SRD> I don't understand this.
> JJ> not sure we need additional text as it is elsewhere described the matching of an OLR to an OCS
>
> [...]
>
>   -- 4.2.2, 2nd to last para:
>   
> I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.
> SRD> We cannot enforce application behavior in a Diameter specification.   I don't see the need for anything more .  Do you have suggested wording?
>
> Ben> Diameter endpoints that throttle requests [ MUST /need to ] do so according to the rules of the client application. Those rules will vary by application, and are beyond the scope of this document.
> SRD> Ok, without the MUST
>
> JJ> We have in the same section:.: "The abatement treatment applied depends on the context of the request". We can write "...depends on the application and on the context of the request". Is it not enough?
SRD> We have the following in the current -06 version.  I think this 
works well enough.

    Diameter endpoints that throttle requests need to do so according to
    the rules of the client application.  Those rules will vary by
    application, and are beyond the scope of this document.

>
> [...]
>
> -- 4.2.3, para 2:
>
> Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id.
> SRD> I guess this matters when an agent is the reporting node
>
> Ben> I think it matters the same if the reporting node is an endpoint. For example, would you consider a host-routed-request with D-H: "foo" to match an host report for host "bar"?  (I'm on the fence here whether that is correct behavior, but I think the behavior should be the same for endpoints and agents.)
>
> Actually, on reflection, how does this affect the scenario of an agent that passes through a host report and generates a realm report? Or a server that generates both?
>
> SRD> Yes, I believe it does.  I suggest we delete paragraph 2, as the
> criteria for matching an OCS will be report type dependent.
>
> JJ>  here 4.2.3 is for the reporting node behavior. It was discussed a while ago if the OCS in the reporting node  was per client (so taking into account the Origin Host of the request or an  OCS common to all clients, so independent of the Origin Host of the request and with the same OLR sent to all clients. The second option (common OCS)  was retained for this draft. The OCS per client would be an option for a further extension.  Si I am OK with the current wording.
>
> -- 4.2.3, last para:
>
> An example of what we have in mind could be helpful here.
> SRD> I'm open to suggested wording...
>
> Ben> Add "For example, it might wait some period of time after overload ends before terminating the OLR, or it might send a series of OLRs indicating progressively less overload severity."
> SRD> Ok
>
> JJ>  Avoiding  oscillation is an important requirement of RFC7068  and this sentence is one in the draft dealing with oscillations.?  A basic oscillation case is the following one, can we a text (in fact a guidance ) on this/ point. There are also somùe relma	ted qtement in
> "e.g a reporting node having requested a strong traffic reduction, then normally a bit later may observe that it is no more overloaded due to the reduced  traffic received, but it should not immediately send an OLR with a small traffic reduction or even terminates the overload condition as this will most probably again result in a strong increase of the incoming traffic as no more reduced, so creating an oscillation."
> This point is somewhat also addressed in the two last paragraphs of 5, in the context of the loss algorithm. This oscillation aspect is more general and so be addressed in this 4.2.3 section
>
> [...]
>
> -- 4.3, para 4:
> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
>
> SRD> i'm not clear on what you are suggesting.
>
> Ben> We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?
>
> SRD> This requires discussion on the list.  I'll start a thread.
>
> JJ> In OC-Supported-Features AVP sent by reacting node, no bit in the OC-Feature-Vector is mandatory except the bit for loss algorithm support. Then if there are additional AVPs in the OC-Supported-Features AVP, they can be ignored except if they are related to a particular feature bit in the OC-Feature-Vector which make this additional AVP mandatory to be supported if the feature is supported by the reporting node.  In any case, the request should not fail.
> If the OLR AVP contains new AVPs, this will be also related to the corresponding feature bit that, if supported,  may require the new AVP be  mandatory in the OLRS sent back by the reporting node.. This will be part of the new feature description introducing additional AVPs. So I do not think we need to say more in this draft. This will be in the extension.
SRD> This has been discussed in a separate thread.
>
> [...]
>
> -- 5.1, para 4:
>
> Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage."
> SRD> Ok.
> JJ> OK on Ben wording but "stateless" can be removed as  mentioned earlier in the section and not directly linked to this sentence.
>
> Then about "...to what the reacting node otherwise would have sent" , this point, I think, is described in 5.3 paragraph 4
>
>
> Best regards
>
> JJacques
>
>
> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Steve Donovan
> Envoyé : mercredi 17 décembre 2014 17:27
> À : [email-masked]
> Objet : Re: [Dime] DOIC WGLC: Editorial Comments
>
>
> On 12/16/14, 9:02 PM, Ben Campbell wrote:
>> Here's some nits, editorial, and structural comments that are generally non-substantive. With the possible exception of comments about 2119 language, most of these could be ignored without consequence, but I think we'd have a better document if we at least thought about them:
>>
>> -- General:
>>
>> We keep referring to the DOIC "solution". I think "mechanism" is more appropriate. I would think of a DOIC "solution" as a deployment that leverages the DOIC "mechanism".
> SRD> I don't see an issue here, as long as we are consistent.
>> We overuse the word Diameter in front of other things. E.g. Diameter nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This entire draft is about Diameter; we don't have to keep saying it. It tends to get awkward when we use it a lot in close proximity.
> SRD> This was done based on feedback from Benoit.  We are being
> explicit.  If there are paragraphs where it is particularly cumbersome, please point out those paragraphs and we can try to make them less cumbersome.
>> Should we put consistently quotes around "loss" when we describe the "loss" algorithm?
>>
>> -- Requirements (2119 language section)
>>
>> This is oddly placed. I'm used to seeing that after the introduction, either stand-alone or as part of a larger terminology section. The RFC editor recommends putting it as section 2.
> SRD> Ok.
>> -- section 2, Abatement Algorithm: "A mechanism..."
>>
>> I suggest "An extensible mechanism..."
> SRD> Ok.
>> -- Section 2, Diversion:
>>
>> Still needs work.  the "by selecting" phrase needs to indicate what does the selecting. "Path" should probably be "path or destination".
>>
>> Proposed text:
>>
>> "An overload abatement mechanism, where the reacting node selects alternate destinations or paths for for requests."
> SRD> I'm ok with this wording.
>> -- section 2, OCS: "Reporting and reacting node internally maintained state..."
>>
>> I suggest "Internal state maintained by a reporting or reacting node..."
> SRD> Ok.
>> -- section 2, Realm-Routed Requests: "... does not know the host that will service..."
>>
>> I suggest: "... does not know which host will service ..."
> SRD> Ok.
>> We should also add a comment that it may be possible to apply diversion to realm routed requests.
> SRD> Where?
>> -- section 2, Throttling: " ... a Diameter Client not sending requests..."
>>
>> I suggest " ... a Client choosing to not send requests ..."
> SRD> A Diameter Client...
>> -- section 3, 2nd paragraph:
>>
>> Client, servers, and agents should not be capitalized. Should "Reporting node" and "Reacting node" be hyphenated?  Consider moving the last sentence to the start of the next paragraph.
> SRD> The capitalization of Diameter Clients, Diameter Servers and
> Diameter agents was Benoit's suggestion to make it explicit what is being referred to.  I don't see the need for hyphenation in this context.  I'm ok with moving the sentence.
>> -- section 3.1, paragraph 1: " This is made possible by adding overload control AVPs, the OC-OLR AVP and the OC- Supported-Features AVP, as optional AVPs into existing commands..."
>>
>> I suggest "This is made possible by adding the optional overload control AVPs OC-OLR and OC-Supported-Features into existing commands."
> SRD> OK.
>> -- section 3.1, 3rd paragraph: "Reporting nodes also include overload reports..."
>>
>> "Reporting nodes _may_ also include overload reports..."
> SRD> OK.
>> -- section 3.1, 4th paragraph: "Clients MAY report..."
>>
>> Should not be normative in this section.
> SRD> Agreed.
>> -- section 3.2, 6th paragraph: "The OC-Feature-Vector AVP will contain..."
>>
>> "... will _always_ contain..."
> SRD> Ok.
>> -- section 3.2, 7th paragraph: " ... all answer messages to requests ..."
>>
>> suggest "... all answers to requests..."
> SRD> Ok.
>> -- section 3.2, paragraph 9: "Reporting nodes are allowed to..."
>>
>> "Reporting nodes can..."
> SRD> Ok.
>> Also consider clarifying that they can change algorithms _between_transactions_, as long as there's no active overload condition.
>>
>> -- section 3.2, paragraph 10 (starting with "The individual features..."
>>
>> Consider moving this entire paragraph to earlier in the section.
>>
>> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
> SRD> This paragraph looks redundant.  I suggest removing it.
>> --> "The DCA mechanism allows..."
>>
>> "... the agent updates the OC-Supported-Features..." --> " ... the agent can update the OC-Supported-Features..."
> SRD> Ok.
>> -- section 3.3, general:
>>
>> Much of this section is redundant to stuff in the parent section. I
>> suggest reducing the parent section detail, and keeping it here. (This
>> may be true for subsequent children of section 3.)
> SRD> Do you have specific suggestions?
>> -- 3.3, third paragraph:
>>
>> s/ , / : /
> SRD> I don't agree.  The commas are there because it is a list.
>> -- 3.3, paragraph 4:
>>
>> In this overview, I suggest text saying that HOST_REPORT indicates a
>> host report, and just using the term "host report" the rest of the
>> time. (Same for realm report)
> SRD> Why?
>> -- 3.3, para 7: "A host-report, for instance, will generally by generated by tracking utilization of resources..."
>>
>> I suggest "A host-report might be generated by tracking use of resources..."
> SRD> OK.
>> -- 3.3, para 9: " ... are responsible for applying the overload abatement algorithm..."
>>
>> I suggest " ... apply the abatement algorithm..."
> SRD> Ok.
>> -- 3.4, para 2: " ... the definition of new report types and the definition of new scopes ..."
>>
>> Aren't these sort of the same thing? That is, you add new scopes by extending report type?
> SRD> Can't you have a how report that applies only to sessions on that host?
>> -- 3.4, para 3:
>>
>> First two sentences are a bit confusing. A new reader will likely think they contradict, without some explanation that OC-Feature-Vector is a child of OC-S-F.
> SRD> They seam clear to me.  Do you have a suggested clarification?
>> -- 3.4, para 4:
>>
>> First sentence has already been stated more than once. No need to repeat here.
> SRD> The first sentence is there to provide context for the second
> sentence.
>> -- 4.1.1, Para 1: "It MAY include the OC-Feature-Vector AVP."
>>
>> consider adding  ", as a sub-avp of OC-Supported-Features."
> SRD> OK
>> - 4.1.1, last paragraph: "This behavior is described in ..."
>>
>> What is the antecedent to "this"? If it's "loss algorithm" behavior, then the reference to section 4.2 should not be needed.
> SRD> Agreed.
>> -- 4.1.2, para 2:
>>
>> It's probably worth reiterating that the reacting node may not be the server, and this requirement may mean inserting AVPS into answers that came from upstream.
> SRD> I don't see the need.  Do you have suggested wording?
>> -- 4.1.2, para 3: "...response messages ... "
>>
>> "... _answer_ messages ..."
> SRD> OK.
> SRD> This paragraph is talking specifically about algorithms and is
> needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.
>> -- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in request messages it receives..."
>>
>> I suspect this should say "... requests that it _forwards_" or "_relays_".
> SRD> To differentiate between the requests that it rejects.  Ok, I think
> relays is the better word.
>> -- 4.1.3, para 5 and 6:
>>
>> Is the reporting node section limited to endpoints? If not, the these paragraphs effectively restate normative language about reporting node behavior from that section. Once we've said what a reporting node normatively has to do, we should just be able to say that an agent acting as a reporting node has all the responsibilities of a reporting node, and not restate the normative requirements.
> SRD> I'm ok with this but it feels like more than an editorial change to me.
>> -- 4.1.3, para 7:
>>
>> The first MAY is a consequence (the complement) of the 2nd MAY. It should at least not be 2119 language, and probably can be omitted entirely.
> SRD> Do you have suggested wording?
>> -- 4.1.3, para 9, last sentence:
>>
>> Does this mean an agent can only change OC-S-F in an answer if it changed it in the request? I don't think we want that restriction, but the context and "as such," seem to scope the MAY to that situation.
> SRD> I don't read it that way.  The first sentence is describing one
> reason why an agent might change OC-S-F.  It doesn't say it is the only reason.
> unambiguously know what to do.  I think ambiguous is the right word.
>> -- 4.2.1.1, para 1:
>>
>> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
> SRD> Do you have suggested wording?
>> -- 4.2.1.2, para 1:
>>
>> Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?
> SRD> Do you have suggested wording?
>> -- 4.2.1.3, para 2:
>>
>> Should this combination include origin-host or origin-realm? App-Id?
> SRD> I don't understand this.
>> -- 4.2.1.3,  para 3: ... a reporting node MUST process..."
>>
>> Should that be "reacting node"?
> SRD> Yes.
>> -- 4.2.1.3, para 4:
>>
>> Paragraph does not make sense. (I think we've already discussed this one from Ulrich's comments).
> SRD> Yes, this is addressed already.
>> -- 4.2.1.3, 3rd para from end: "... update the OCS entry as being expired."
>>
>> I suggest language like " invalid" or "terminated". I take "expired"
>> to mean "naturally expired", which is different from the case
>> described here. There may be subtle behavior difference. (For example,
>> a reacting node might choose to log "expirations" differently than
>> "explicit terminations".)
> SRD> For the context of this specification I think expired works.
> Implementations can differentiate types of expired if they have a reason.  Nothing here prevents that.
>> -- 4.2.1.4, para 9: "... including the reduction percentage..."
>>
>> I suggest "... including, for example, the reduction percentage..."
> SRD> OK.
>> -- 4.2.1.4, para 11: " ... MUST update the sequence number ..."
>>
>> I suggest s / update / increment
> SRD> OK.
>> -- 4.2.2, 2nd to last para:
>>
>>    I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.
> SRD> We cannot enforce application behavior in a Diameter
> specification.   I don't see the need for anything more .  Do you have
> suggested wording?
>> -- 4.2.3, para 2:
>>
>> Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id.
> SRD> I guess this matters when an agent is the reporting node.
>> -- 4.2.3, paras 8 and 9:
>>
>> We put the currently less favored approach first, with the favored approach in the following paragraph. I suggest we put the more favored approach first.
> SRD> OK.
>>
>> -- 4.2.3, last para:
>>
>> An example of what we have in mind could be helpful here.
> SRD> I'm open to suggested wording...
>>
>> -- 4.3, para 4:
>>
>> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
> SRD> i'm not clear on what you are suggesting.  Do you have suggested
> wording?
>> -- 4.3, para 5:
>>
>> Why is it different depending on whether the feature is an algorithm or not? Also, isn't this mostly redundant to the paragraph about new normative behavior?
> SRD> I agree, this paragraph can be removed.
>> -- 4.3, para 6, last sentence
>>
>> This is redundant to earlier normative language in the section
>> (assuming a new report type will always involve new normative
>> behavior.)
> SRD> I agree, the last sentence can be removed.
>> -- 4.3, para 7, last sentence
>>
>> Also redundant
> SRD> Agreed.
>> -- 4.3, last para, last sentence:
>>
>> It's not clear if this means section 8 of this doc, or 6733. I suggest putting this sentence before the subsequent one.
> SRD> OK.
>> -- 5.1, para 4:
>>
>> Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage."
> SRD> Ok.
>> We should also clarify that this reduction is in comparison to what the reacting node otherwise would have sent, rather than what it may have previously sent.
> SRD> Isn't this already covered?  Do you have suggested wording?
>> -- 5.3, para 5:
>>
>> Needs a sentence or paragraph to describe the 100% issue before describing how to back down from it.
> SRD> It's discussed earlier in the document.  I'm ok with adding it
> again.  Do you have suggested wording?
>> "... following concerns are RECOMMENDED ..."
>>
>> following procedures...?
> SRD> OK.
>> -- 5.3, para 6: "... does not receive an OLR in messages sent to the formerly overloaded node..."
>>
>> Do we mean "... does not receive an OLR in answers received from the formerly overloaded node..."?
> SRD> Agreed.
>> -- para 6, last paragraph
>>
>> Paragraph is off topic for section. It probably belongs in the extensibility section, or at least somewhere other than here.
> SRD> Do you mean section 6? This isn't about extensibility but about how
> Diameter applications integrate DOIC.  It probably belongs in the intro or overview sections.
>> -- 6.1, last para:
>>
>> I think we moved this to 6.2, but forgot to delete it here.
> SRD> Yup, already addressed as part of Ulrich's comments.
>> -- 6.2:
>>
>> Why did the AVP code jump to TBD6? (Also seems out of order in the
>> table.)
> SRD> Historical reasons.  Doesn't matter, the real values will be filled
> in eventually.
>> Is it to late to rename the value to OLR_LOSS_ALGO?
> SRD> Yes. :-)
>> -- 9.4, para 2: "A node MUST not..."
>>
>> "A node MUST _NOT_ ..."
> SRD> Ok.
>> -- References:
>>
>> 5905 and 5729 are not cited in the document.
> SRD> Ok.
>> draft-ietf-dime-e2e-sec-req-00: Outdated version.
> SRD> Ok.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>