Subject: [Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07

From: Kevin Lingle <[email-masked]>
Date: Mon, 29 Sep 2003 16:00:25 -0400

Mary Barnes wrote:

<snip>

> 
>>- Section 9, page 109.  The statement "If these objects are SET
> 
> maliciously,
> 
>>it may result in
>>incorrect or unwanted protocol operation." is probably a bit of an
>>understatement with regards to the timer, retry and expire values being
>>misconfigured. Certainly, a well designed system would but reasonable
>>boundaries on how these things can be configured, so as to hopefully
> 
> prevent
> 
>>significant problems.  Cullen had brought up the more general issue of
>>whether all the timers should be configurable in his comments. Like
> 
> Cullen,
> 
>>I haven't thought about this enough to decide whether all these timers
>>should be configurable, but at a minimum, I think the  security section
>>needs a more robust statement.
> 
> 
> is this commented wrt the entire security section or just the area
> you referred to on pg 109?
> 
> is it that we have not made a strong enough statement about the
> protocol impact to these particular timer/retry related objects
> being SET??
> 
> [MB] This comment was specific to the timer/retry and related objects being
> set.  My point was that it's beyond being incorrect or unwanted protocol
> operation, but rather has a broader impact on the server and its ability to
> process new and existing transactions and the clients making use of the
> server.  I think, though, that the broader question is whether all of these
> should be configurable, per Cullen's comments. 

ok.  here's where we stand with cullen's comments.

we are not going to prevent configuration via the mib, but we are
going to rework the complicance section of the to not require
configuration to be mandatory.  essentially defining the necessary
optional object-groups to allow one to be compliant with the mib
but not support and configurability.

that said, set capability will still be allowed for the objects in
question for your comment, so we need to just emphasize what you've
said above.  serious damage to the basic operation of the system
can occur if these objects are set maliciously (or out of ignorance
for that matter).   we can state that set capability is not mandatory.

kevin
> 
> thanks!
> kevin
> 
> 
>>Regards,
>>Mary H. Barnes
>>[email-masked]
>>
>>
>>
>>
>>
>>
> 
> 
> 

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Kevin R. Lingle       919.392.2029
  http://www.klove.com                               http://www.air1.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 29 Sep 2003 13:28:26 -0500

I've snipped the email to just respond to 2 points [MB]:

-----Original Message-----
From: Kevin Lingle [mailto:[email-masked]]
Sent: Monday, September 29, 2003 12:05 PM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: Jean-Francois Mule; [email-masked]'; [email-masked]'
Subject: Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07

mary,

responding to the nits/general comments....

----1st part of response snipped by Mary-----------

> 
> - Section 8:  My understanding is that this section should be removed by
the
> RFC Editor.  Thus, I would suggest adding a comment as such (something
like:
> "This section to be removed by RFC Editor before publication." and moving
> this section just prior to the Author's address to facilitate that
process. 

done (patially).  i added the line you suggested to the section, but
didn't move the section.   the xml2rfc tool we've started using appears
rather ridge in some of the "template" sections.  i'm not exactly certain
on altering the order of sections that are part of the <back></back>.
how important is it that we move this section since it will be removed
anyway?

[MB] That's fine. This was just a suggestion to simplify the final editorial
process (i.e. section numbering).

maliciously,
prevent
Cullen,

thanks!
kevin