Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-lne-model-05

[Lou Berger <[e-mail]>]

Hi,

     Sorry about the slow response.  See below.

On 2/8/2018 8:36 AM, Alissa Cooper wrote:
> Russ, thanks for your review. I don’t think your major concern quite rises to the level of being DISCUSS-worthy, but I’ve flagged it in my No Objection ballot and would expect a response from the authors.
>
> Alissa
>
>> On Jan 20, 2018, at 6:36 PM, Russ Housley <[e-mail]> wrote:
>>
>> Reviewer: Russ Housley
>> Review result: Not Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-rtgwg-lne-model-05
>> Reviewer: Russ Housley
>> Review Date: 2018-01-20
>> IETF LC End Date: 2018-01-31
>> IESG Telechat date: 2018-02-08
>>
>> Summary: Not Ready
>>
>> Major Concerns:
>>
>> Section 4 listed three data nodes that are sensitive or vulnerable:
>>    -  /logical-network-elements/logical-network-element
>>    -  /logical-network-elements/logical-network-element/managed
>>    -  /if:interfaces/if:interface/bind-lne-name
>>
>> All three of them deserve a bit more discussion, although the middle
>> one is covered in much more detail than the other two.  If a bad actor
>> gets "unauthorized access" is there something more specific about each
>> of these that can be said?  The characterization of "network
>> malfunctions, delivery of packets to inappropriate destinations, and
>> other problems" seems very broad.  Consequences that are specific to
>> these data nodes would be more helpful to the reader.
We've been struggling what more should be said here - and this the 
reason for the delayed response - note that the text does pay particular 
note to the one really special node in the model:

    /logical-network-elements/logical-network-element/managed:  While
       this leaf is contained in the previous list, it is worth
       particular attention as it controls whether information under the
       LNE mount point is accessible by both the host device and within
       the LNE context.  There may be extra sensitivity to this leaf in
       environments where an LNE is managed by a different party than the
       host device, and that party does not wish to share LNE information
       with the operator of the host device.

Furthermore, the current text is largely pattered after what is 
typically covered in YANG models and we don't see this model as having  
fundamentally different than the reference foundational YANG models.  
-06 does add important text on secure data access and and access control 
of specific operations.  Is this sufficient?

>> Minor Concerns:
>>
>> Section 1.1: Please update the first paragraph to reference RFC 8174
>> in addition to RFC 2119, as follows:
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>    "OPTIONAL" in this document are to be interpreted as described in BCP
>>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>    capitals, as shown here.

Done (in -06)

>>
>> Nits:
>>
>> Abstract: YANG appears in the title and the introduction.  So, I was a
>> bit surprised that YANG did not appear anywhere in the Abstract.
Done (in -06)
>> This document seems to refer to itself as "RFC XXXX" and "RFC TBD".
>> Please pick one and use it throughout the document.
Done (in -06)

Thanks,
Lou (and co-authors)

>>
>> _______________________________________________
>> Gen-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg