Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

That works for me. I will clear the DISCUSS.

Thanks!

Ben.

On 16 May 2016, at 9:46, Eric Voit (evoit) wrote:

> Hi Ben,
>
>
>
> There is no issue with rewording to a requirement rather than an 
> intro.  The second sentence below has been changed to meet 2119.
>
>
>
> Some uses of this Subscription Service will push privacy-sensitive 
> updates and metadata.  For privacy-sensitive deployments, subscription 
> information MUST be bound within secure, encrypted transport layer 
> mechanisms.  For example if NETCONF is used as transport, then 
> [RFC5539] would be a valid option to secure the transported 
> information.  The Subscription Service can also be used with emerging 
> privacy-sensitive deployment contexts as well.  As an example, 
> deployments based on [i2rs-usecase] would apply these requirements in 
> conjunction with those documented within [i2rs-environment-security] 
> and [i2rs-protocol-security] to secure ephemeral state information 
> being pushed from a Network Element.
>
>
>
> Eric
>
>
>
>> From: Ben Campbell, May 15, 2016 3:18 PM
>
>>
>
>> Hi Eric and Sue,
>
>>
>
>> Thanks for the change, and I think it's on the right track. But I 
>> notice most of the
>
>> other requirements, in the security considerations section and in 
>> other sections,
>
>> use 2119 keywords. Is there a reason not to do so here? Would it be 
>> reasonable
>
>> to say that any embodiment of these requirements MUST support a 
>> transport
>
>> that provides encryption and integrity protection, and such a 
>> transport MUST be
>
>> used when carrying privacy-sensitive information?
>
>>
>
>> Thanks!
>
>>
>
>> Ben.
>
>>
>
>>
>
>> On 13 May 2016, at 10:49, Susan Hares wrote:
>
>>
>
>>> Eric:
>
>>>
>
>>>
>
>>>
>
>>> Thanks for jumping in and putting out text that resolves Ben’s
>
>>> comments.  This text works for me with one addition.  Add reference 
>>> to
>
>>> the security environment draft.
>
>>>
>
>>>
>
>>>
>
>>> Sue
>
>>>
>
>>>
>
>>>
>
>>> From: Eric Voit (evoit) [mailto:[e-mail]]
>
>>> Sent: Friday, May 13, 2016 11:26 AM
>
>>> To: Susan Hares; Ben Campbell; Alia Atlas 
>>> ([e-mail]<mailto:[e-mail]>)
>
>>> Cc: The IESG; [e-mail]<mailto:[e-mail]>;
>
>>> [e-mail]<mailto:[e-mail]>; 
>>> [e-mail]<mailto:[e-mail]>
>
>>> Subject: RE: [i2rs] Ben Campbell's Discuss on
>
>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)
>
>>>
>
>>>
>
>>>
>
>>> Hi Ben,
>
>>>
>
>>>
>
>>>
>
>>> I have added the text below as the lead-in to section 4.2.5.  I
>
>>> believe this meets the intents of your suggestions below.
>
>>>
>
>>>
>
>>>
>
>>> Hi Susan & Alia,
>
>>>
>
>>>
>
>>>
>
>>> I have uploaded v08 of
>
>>>
>
>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
>
>>>
>
>>> If Ben concurs with the text below, I am not aware of any remaining
>
>>> discuss items.
>
>>>
>
>>>
>
>>>
>
>>> Thanks everyone for your reviews,
>
>>>
>
>>> Eric, Alex, & Alberto
>
>>>
>
>>>
>
>>> 4.2.5.  Security Requirements
>
>>>
>
>>>    Some uses of this Subscription Service will push 
>>> privacy-sensitive
>
>>>    updates and metadata.  Good deployment practices will bind this
>
>>>    generated information within secure, encrypted transport layer
>
>>>    mechanisms.  For example if NETCONF is used as transport, then
>
>>>    [RFC5539] would be a valid option to secure the transported
>
>>>    information.  The Subscription Service can also be used with
>
>>> emerging
>
>>>    deployment contexts as well.  As an example, deployments based on
>
>>>    [i2rs-usecase] can apply these requirements in conjunction with
>
>>> those
>
>>>    documented within [i2rs-protocol-security] to secure ephemeral
>
>>> state
>
>>>    information being pushed from a Network Element.
>
>>>
>
>>>
>
>>>
>
>>>
>
>>> From: Susan Hares [mailto:[e-mail]]
>
>>> Sent: Friday, May 06, 2016 7:09 PM
>
>>> To: Ben Campbell
>
>>> Cc: Eric Voit (evoit); The IESG; 
>>> [e-mail]<mailto:[e-mail]>;
>
>>> [e-mail]<mailto:[e-mail]>; 
>>> [e-mail]<mailto:[e-mail]>
>
>>> Subject: Re: [i2rs] Ben Campbell's Discuss on
>
>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)
>
>>>
>
>>>
>
>>>
>
>>> Ben:
>
>>>
>
>>>
>
>>>
>
>>> This is wise idea.  I will suggest some text to Eric and you in the
>
>>> morning.
>
>>>
>
>>>
>
>>>
>
>>> Sue
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
>
>>>
>
>>> -------- Original message --------
>
>>>
>
>>> From: Ben Campbell <[e-mail]<mailto:[e-mail]>>
>
>>>
>
>>> Date: 5/6/2016 2:38 PM (GMT-06:00)
>
>>>
>
>>> To: Susan Hares <[e-mail]<mailto:[e-mail]>>
>
>>>
>
>>> Cc: Eric Voit <[e-mail]<mailto:[e-mail]>>, The IESG 
>>> <[e-mail]<mailto:[e-mail]>>,
>
>>> [e-mail]<mailto:[e-mail]>, 
>>> [e-mail]<mailto:[e-mail]>,
>
>>> [e-mail]<mailto:[e-mail]>
>
>>>
>
>>> Subject: Re: [i2rs] Ben Campbell's Discuss on
>
>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)
>
>>>
>
>>>
>
>>>
>
>>> Hi Susan,
>
>>>
>
>>> To be clear, I do not object to the wider context per se. My concern
>
>>> is
>
>>> that the security and privacy requirements are left as implicit, 
>>> based
>
>>> on the more narrow i2rs/netconf context. I only mentioned the
>
>>> potential
>
>>> of restricting the contextas one possible way forward; I am 
>>> certainly
>
>>> not wedded to it.
>
>>>
>
>>> My suggestion for a way forward would be to document the high level
>
>>> security and privacy requirements in this document. IIUC, the larger
>
>>> context includes potentially unknown contexts, so some of this may
>
>>> need
>
>>> to be conditional. For example, language like the following might be
>
>>> helpful (this is just an example--I don't mean to say that it is 
>>> true
>
>>> or
>
>>> applicable):
>
>>>
>
>>>   "Some uses of this mechanism may carry privacy-sensitive
>
>>> information,
>
>>> or generate    privacy-sensitive metadata through the subscription
>
>>> mechanism. In contexts where this is true, the following 
>>> requirements
>
>>> apply..."
>
>>>
>
>>> It might also be reasonable to say that, for the context of i2rs,
>
>>> these
>
>>> requirements are documented in [references] and are expected to be
>
>>> fulfilled by the [transport and or protocol]
>
>>>
>
>>> Eric's email also suggested that the actual transport of data from 
>>> the
>
>>> Yang datastore may be out of scope for these requirements. I don't
>
>>> object to that, either, as long as it is clear and explicit, 
>>> although
>
>>> it
>
>>> would be good to point to where it is _in_ scope.
>
>>>
>
>>> Thanks!
>
>>>
>
>>> Ben.
>
>>>
>
>>> On 6 May 2016, at 1:06, Susan Hares wrote:
>
>>>
>
>>>> Ben:
>
>>>>
>
>>>> This is the first of the "re-use" management protocols.  The
>
>>>> requirements
>
>>>> are set-up so that we can suggest additions to the NETCONF and
>
>>>> RESTCONF for
>
>>>> this first of I2RS.
>
>>>>
>
>>>> The I2RS ephemeral work, pub/sub, traceability, and security are
>
>>>> target at
>
>>>> the I2RS protocol definition with the I2RS use case.  However, 
>>>> since
>
>>>> these
>
>>>> are general additions to NETCONF/RESTCONF, this work can be used
>
>>>> elsewhere.
>
>>>>
>
>>>> I think the text you are highlighting has this larger context.   
>>>> Now,
>
>>>> one of
>
>>>> the really important things to chat with Alia and Benoit is how do 
>>>> we
>
>>>> handle
>
>>>> the wider use case.   Do we mention the wider context?
>
>>>>
>
>>>> The WG thought mentioning it was important.
>
>>>>
>
>>>> Sue
>
>>>>
>
>>>> -----Original Message-----
>
>>>> From: Ben Campbell [mailto:[e-mail]]
>
>>>> Sent: Thursday, May 05, 2016 5:31 PM
>
>>>> To: Susan Hares
>
>>>> Cc: Eric Voit; The IESG; [e-mail]<mailto:[e-mail]>;
>
>>>> [e-mail]<mailto:[e-mail]>; 
>>>> [e-mail]<mailto:[e-mail]>
>
>>>> Subject: Re: [i2rs] Ben Campbell's Discuss on
>
>>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)
>
>>>>
>
>>>> On 5 May 2016, at 5:15, Susan Hares wrote:
>
>>>>
>
>>>>> Eric, Ben and IESG members:
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> The pub/sub requirements are part of a 5 part requirements.   May 
>>>>> I
>
>>>>> quote
>
>>>>> from the shepherd's report:
>
>>>>>
>
>>>>> ---------------------
>
>>>>>
>
>>>>> The requirements for the first version of I2RS are:
>
>>>>>
>
>>>>> 1) model driven ephemeral state - that is data models that do not
>
>>>>> survive
>
>>>>>
>
>>>>>     a software or hardware reboot.
>
>>>>>
>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> 2) a secure protocol -
>
>>>>>
>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req
>
>>>>> uireme
>
>>>>> nts/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> 3) traceability - ability to record interactions between I2RS
>
>>>>> elements
>
>>>>>
>
>>>>> (Client, Agent, Routing system)
>
>>>>>
>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> 4) notification publication via subscription
>
>>>>>
>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> 5) Protocol to pass Data for Analytics
>
>>>>>
>
>>>>> The first version of these requirements does not include a
>
>>>>>
>
>>>>> separate analytical protocol requirements as the simple use cases
>
>>>>> may
>
>>>>>
>
>>>>> pass information via query/poll or the notifications.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> The I2RS protocol exists in an secure environment described by:
>
>>>>>
>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-
>
>>>>> reqs/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> -------------------------
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Eric - Perhaps it would be good to point to:
>
>>>>>
>
>>>>> .         draft-ietf-i2rs-protocol-security-requirements and
>
>>>>>
>
>>>>> .         draft-ietf-i2rs-security-environment-reqs/
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Ben - Can you tell me how the shepherd report could have been
>
>>>>> clearer?
>
>>>>>  The
>
>>>>> I2rs protocol security requirements require:  confidentiality,
>
>>>>> encryption, secure transport, protection against replay attack,
>
>>>>> protection against DDoS attack (if possible).
>
>>>>
>
>>>> I think my confusion lies in the fact that, while the shepherd's
>
>>>> writeup
>
>>>> styles this draft as part of the I2RS protocol requirements, the
>
>>>> draft
>
>>>> itself claims to describe requirements for a generally useful 
>>>> pub-sub
>
>>>> interface to a yang datastore. It's not clear to me how and when 
>>>> the
>
>>>> I2RS
>
>>>> protocol security requirements apply to it. If the described
>
>>>> interface
>
>>>> is
>
>>>> intended to be useful in contexts other than I2RS (and the draft
>
>>>> explicitly
>
>>>> sets that expectation in 2.2), it needs to talk more generally 
>>>> about
>
>>>> security and privacy.
>
>>>>
>
>>>> For example, it might make sense to say that certain security
>
>>>> requirements
>
>>>> apply in environments where the mechanism might carry privacy
>
>>>> sensitive
>
>>>> data, and then point to the i2rs requirements for when the 
>>>> mechanism
>
>>>> is used
>
>>>> in an I2RS context.
>
>>>>
>
>>>> A different approach might be to more tightly constrain this to 
>>>> i2rs
>
>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Ben - On opting in, once the receive accepts a transport 
>>>>> connection
>
>>>>> from the I2RS server - how is this not an opt-in to receive data?
>
>>>>> What
>
>>>>> are you looking for?
>
>>>>
>
>>>> I guess that depends on the transport. The transport requirements 
>>>> say
>
>>>> the
>
>>>> mechanism has to work over multiple transports. The last paragraph 
>>>> in
>
>>>> 4.2.4
>
>>>> says "In the case of connection-oriented transports..." which
>
>>>> suggests
>
>>>> that
>
>>>> non-connection-oriented transports are possible.
>
>>>>
>
>>>> Even with a connection-oriented transport, this may depend on how
>
>>>> connection-management is handled, and whether the receiver might be
>
>>>> receiving things it _wants_ to receive on the same transport.
>
>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Sue Hares
>
>>>>>
>
>>>>> (shepherd)
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> -----Original Message-----
>
>>>>> From: i2rs [mailto:[e-mail]] On Behalf Of Eric Voit
>
>>>>> (evoit)
>
>>>>> Sent: Wednesday, May 04, 2016 7:25 PM
>
>>>>> To: Ben Campbell; The IESG
>
>>>>> Cc: [e-mail]<mailto:[e-mail]>; 
>>>>> [e-mail]<mailto:[e-mail]>;
>
>>>>> [e-mail]<mailto:[e-mail]>; 
>>>>> [e-mail]<mailto:[e-mail]>
>
>>>>> Subject: Re: [i2rs] Ben Campbell's Discuss on
>
>>>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and 
>>>>> COMMENT)
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Hi Ben,
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Thanks for the comment.   In-line....
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>> From: Ben Campbell, May 04, 2016 2:49 PM
>
>>>>>
>
>>>>>> ----------------------------------------------------------------------
>
>>>>>
>
>>>>>> DISCUSS:
>
>>>>>
>
>>>>>> ----------------------------------------------------------------------
>
>>>>>
>
>>>>>>
>
>>>>>
>
>>>>>> I have a couple of points I would like to discuss. Hopefully they
>
>>>>>> can
>
>>>>>
>
>>>>>> be resolved
>
>>>>>
>
>>>>>> easily:
>
>>>>>
>
>>>>>>
>
>>>>>
>
>>>>>> Are there really no requirements for privacy or integrity
>
>>>>>> protection?
>
>>>>>
>
>>>>>> Is there an expectation that this mechanism would ever carry
>
>>>>>> privacy
>
>>>>>
>
>>>>>> sensitive or otherwise sensitive information?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> [eric's comment:
>
>>>>>
>
>>>>> When the subscription is established dynamically via an existing
>
>>>>> transport
>
>>>>> session (which is expected to be the dominant case) we have the 
>>>>> same
>
>>>>> expectations for Privacy and integrity as would be provided via a
>
>>>>> "GET"
>
>>>>> instead of a "PUSH" over the same transport.   We could have
>
>>>>> replicated all
>
>>>>> these requirements, but that was seen as unnecessary and likely 
>>>>> less
>
>>>>> secure
>
>>>>> than adopting existing mechanisms.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> When the Subscriber and Receiver are different, then the transport
>
>>>>> connection will have credentials passed as part of the
>
>>>>> establishment.
>
>>>>> These
>
>>>>> credentials will be used as a Security Grooming Filter just like 
>>>>> the
>
>>>>> above
>
>>>>> case so that pushed objects will be excluded from an Update
>
>>>>> Notification as
>
>>>>> per the permissions of the Receiver.   (I.e., this is identical
>
>>>>> behavior to
>
>>>>> the above.)    As several people have had questions about this, 
>>>>> the
>
>>>>> new v07
>
>>>>> will make this explicit in the Security section.
>
>>>>>
>
>>>>> End of eric's comment]
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Sue: The transport provides for privacy, integrity protection.
>
>>>>> Most
>
>>>>> configuration in network boxes would need privacy.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>> - 4.2.5, 2nd to last paragraph:
>
>>>>>
>
>>>>>> I am surprised to find that, when the receiver is not the
>
>>>>>> subscriber,
>
>>>>>
>
>>>>>> that the receiver is expected to opt-out. It seems like some form
>
>>>>>> of
>
>>>>>
>
>>>>>> opt-in or affirmative consent would be needed here.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> The question really was how heavy-weight should the mechanism be.
>
>>>>> Transports been considering are all encrypted.  So there is 
>>>>> already
>
>>>>> a
>
>>>>> level
>
>>>>> of trust between the peers.  And a target can always pull down the
>
>>>>> connection if there are issues.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> In addition, multicast transports are viable for some future 
>>>>> cases.
>
>>>>> We
>
>>>>> didn't want mechanisms which complicated this type of interaction,
>
>>>>> especially in a world where dumb IoT devices may be involved.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Sue: If the receiver accepts a secure transport set-up from the
>
>>>>> server, can
>
>>>>> you provide the reason why this is not an "opt-in" once it 
>>>>> receives
>
>>>>> the
>
>>>>> connection from the I2RS agent?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>> ----------------------------------------------------------------------
>
>>>>>
>
>>>>>> COMMENT:
>
>>>>>
>
>>>>>> ----------------------------------------------------------------------
>
>>>>>
>
>>>>>>
>
>>>>>
>
>>>>>> - General: I support Stephen's DISCUSS
>
>>>>>
>
>>>>>>
>
>>>>>
>
>>>>>> -2.2: What is the real scope of this work? Is it expected to
>
>>>>>> supplant
>
>>>>>
>
>>>>>> the mentioned mechanisms?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> No.   It is just showing that many specialized Push mechanism 
>>>>> exist.
>
>>>>> This
>
>>>>> is not intended to supplant existing mechanisms, although perhaps 
>>>>> it
>
>>>>> can
>
>>>>> help avoid future dedicated solutions.
>
>>>>>
>
>>>>>> - 2.3: "We need a new pub-sub
>
>>>>>
>
>>>>>>    technology"
>
>>>>>
>
>>>>>> The shepherd write up mentioned a goal to use existing
>
>>>>>> technologies.
>
>>>>>
>
>>>>>> Is the point of this sentence to suggest that is not feasible?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Existing technologies cannot meet all the requirements specified.
>
>>>>> There are
>
>>>>> technology drafts progressing in NETCONF which can.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>> - 4.1, 4th paragraph:
>
>>>>>
>
>>>>>> The MAY doesn't seem right--is this a statement of fact that the
>
>>>>>
>
>>>>>> subscriber may have to resubscribe, or a requirement of the form
>
>>>>>> that
>
>>>>>
>
>>>>>> the service MAY force the subscriber to resubscribe? (Be careful
>
>>>>>> with
>
>>>>>
>
>>>>>> MAYs in requirements language--they imply unexpected things. For
>
>>>>>
>
>>>>>> example, several requirements say a SUBSCRIBE MAY do 
>>>>>> something--do
>
>>>>>
>
>>>>>> those imply that the service MUST allow the subscriber to do it 
>>>>>> ?)
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Good point.   Reworded in v07.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>>> -- 4.2.2, third bullet: The previous section said dampening 
>>>>>> periods
>
>>>>>
>
>>>>>> MUST be supported.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Yes, but dampening is never for periodic subscriptions.
>
>>>>>
>
>>>>>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it 
>>>>>> means
>
>>>>>> to
>
>>>>>
>
>>>>>> change the what subtrees the subscription applies to, but could 
>>>>>> be
>
>>>>>
>
>>>>>> interpreted to change the subtrees themselves.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Fixed
>
>>>>>
>
>>>>>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery 
>>>>>> but
>
>>>>>
>
>>>>>> gave the subscriber a way to reconstruct the order fulfill this
>
>>>>> requirement?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Yes, the timestamp within an update.  But this requirement targets 
>>>>> a
>
>>>>> specific object in a specific subscription.  So there should be no
>
>>>>> issues.
>
>>>>>
>
>>>>>> Nits:
>
>>>>>
>
>>>>>> - The shepherd write up suggests this is standards track. The 
>>>>>> draft
>
>>>>>
>
>>>>>> and tracker both say informational. Please update the shepherd 
>>>>>> writ
>
>>>>>> up.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Fixed
>
>>>>>
>
>>>>>> -3, last paragraph: What's the difference between a "Push" and an
>
>>>>> "Update"?
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Reworded
>
>>>>>
>
>>>>>> -4.1: A forward reference to the subscription QoS section would 
>>>>>> be
>
>>>>> helpful.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Moved the requirement in question to 4.2.6.
>
>>>>>
>
>>>>>> -- Last paragraph, last sentence: Sentence doesn't parse.
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Fixed
>
>>>>>
>
>>>>>>
>
>>>>>
>
>>>>>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY
>
>>>>>
>
>>>>>
>
>>>>>
>
>>>>> Fixed
>
>>>>>
>
>>>>> Thanks again for the review!
>
>>>>>
>
>>>>> Eric
>
>>>>>
>
>>>>> _______________________________________________
>
>>>>>
>
>>>>> i2rs mailing list
>
>>>>>
>
>>>>>  <mailto:[e-mail]> [e-mail]<mailto:[e-mail]>
>
>>>>>
>
>>>>>  <https://www.ietf.org/mailman/listinfo/i2rs>
>
>>>>> https://www.ietf.org/mailman/listinfo/i2rs