Re: [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stewart,

Thanks for taking the time to review !

Please see inline and let us know your input.


> On Jan 3, 2017, at 10:11 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-insipid-logme-reqs-11
> Reviewer: Stewart Bryant
> Review Date: 2017-01-03
> IETF LC End Date: 2017-01-13
> IESG Telechat date: unknown
> 
> Summary: Ready with minor issue
> 
> This is a well written document that describes a useful feature in
> its intended purpose. However I could not help but think that it has
> an inevitable alternate use in the observation of users. There is
> guidance on how to prevent this, but that seems easily ignored. Thus
> the guidance from Security Area review will be of particular importance.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> 6.1.  Trust Domain
> 
>   Since a "log me" marker may cause a SIP entity to log the SIP header
>   and body of a request or response, the "log me" marker SHOULD be
>   removed at a trust domain boundary.
> 
> 
> SB> I am not convinced that SHOULD is strong enough given that the traffic
> SB> is leaving the trust domain.

We can change from SHOULD to MUST.



> 
> Nits/editorial comments:
> 
> 
> 3.1.  Network Boundary
> 
>   Figure 2 shows a network boundary between GW-A1
>   in operator A's network and the SBC in operator B's network.  A
> 
> SB> SBC needs expanding on first use.


We will change it to “…and the Session Border Controller (SBC)…”.

> 
> ===================
> 
>   [RFC5853] gives examples of manipulating signaling to prevent the
>   sending network passing on sensitive information, for example
>   topology hiding, or the receiving network protecting itself from
>   signaling that is not under its control, for example protocol repair.
> 
> SB> The last sentence does not scan well.


We can rewrite this paragraph as follows:
   
   Topology hiding and protocol repair (see [RFC5853]) are two common 
   functions that manipulate signaling at the network boundary. These 
   functions are performed by SIP device types  (see [RFC7092]) such as
   Session Border Controller and Interconnection Border Control Function (IBCF).
  

> 
> ===================
> 
>   o  REQ9: The "log me" marker mechanism SHOULD allow a SIP
>      intermediary to request logging SIP requests and responses on
>      behalf of the originating endpoint.  The typical use case for this
>      requirement is for compatibility with UAs that have not
> 
> SB> UA needs expanding on first use.

We will change it to “….with User Agents (UA) that have not …"

Thanks!
Arun

> 
> 
> 
> _______________________________________________
> insipid mailing list
> insipid@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/insipid





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]