From: Randy Turner (rturner@amalfisystems.com)
Date: Mon Feb 02 2009 - 15:23:45 EST
Right - I had a brain fizzle thinking that ATR was an acronym like the
other examples SOH=statement of health, etc.
The ATR is the attributes document that we've been working on...
Just a note to anyone else on the list, I took an action item to
spend time on the NEA/TNC mapping document on a previous teleconference.
I was hoping to use the NAP mapping document as an outline (ideally
structuring the document according to the TOC of the NAP document).
I will take a look at the NAP document to see if it's possible to
reuse the basic structure of this document for NEA. It would be nice
if mapping documents
had a similar TOC (table of contents)
Randy
On Feb 2, 2009, at 12:04 PM, Brian Smithson wrote:
> Randy,
>
> This is all correct except that the ATR document isn't a change,
> it's the document that we've already drafted (and Jerry just posted
> an update today).
> --
> Regards,
> Brian Smithson
> PM, Security Research
> PMP, CISSP, CISA, ISO 27000 PA
> Advanced Imaging and Network Technologies
> Ricoh Americas Corporation
> (408)346-4435
>
>
> Randy Turner wrote:
>>
>>
>> Ok, so when we're done, we would have 3 documents that the PWG/IDS
>> group authors:
>>
>> [HCD-ATR]
>> [HCD-NAP]
>> [HCD-NEA] or [HCD-TNC], depending on your perspective
>>
>> and these documents would reference [MS-SOH], [IETF-NEA], etc.
>>
>> If I have captured your proposal correctly, then the ATR document
>> is the only change to what we've been doing. correct?
>>
>> Randy
>>
>>
>> On Feb 2, 2009, at 11:24 AM, Brian Smithson wrote:
>>
>>> Randy,
>>>
>>> Well, now I'm not sure what I'm proposing :-).
>>>
>>> By "IDS mapping document", do you mean a document that contains
>>> describes how the IDS attributes apply to all of the schemes that
>>> we plan to support, e.g. NAP, NEA, TNC, ...?
>>>
>>> What I was think I was proposing was something like this:
>>> [MS-SOH] specifies what is expected to support NAP. Other non-PWG
>>> documents specify what is expected for other schemes (NEA, TNC...).
>>> [HCD-ATR] specifies the HCD-specific attributes that shall/should
>>> be supported in all schemes.
>>> [HCD-NAP] specifies how the HCD-specific attributes are mapped to
>>> [MS-SOH], and if necessary, also contains describes how the
>>> standard NAP attributes should be interpreted when applied to
>>> HCDs. It would fully specify the bits and bytes of NAP support for
>>> HCDs, including both the standard NAP stuff and the HCD-specific
>>> stuff. [HCD-NEA], [HCD-TNC], ... would do the same thing for other
>>> schemes.
>>> There would be some information in [HCD-NAP] that is also
>>> presented in [MS-SOH] and [HCD-ATR], and we would need to be
>>> careful to ensure that they stay in sync. I think that the main
>>> distinction between them would be that the protocol binding spec
>>> would focus on the bits and bytes, and the other documents
>>> (particularly [HCD-ATR]) would contain more descriptive information.
>>> --
>>> Regards,
>>> Brian Smithson
>>> PM, Security Research
>>> PMP, CISSP, CISA, ISO 27000 PA
>>> Advanced Imaging and Network Technologies
>>> Ricoh Americas Corporation
>>> (408)346-4435
>>>
>>>
>>> Randy Turner wrote:
>>>>
>>>> Hi Brian,
>>>>
>>>> I think what you're really proposing is that there would be an
>>>> "IDS mapping document" and not a NAP document. This one document
>>>> would be single
>>>> reference for implementers. Does this sound right?
>>>>
>>>> Randy
>>>>
>>>>
>>>> On Feb 2, 2009, at 10:42 AM, Brian Smithson wrote:
>>>>
>>>>> Regarding the new NAP draft:
>>>>>
>>>>> I tried to remove information that was already specified in
>>>>> other specs (MS-SOH and HCD-ATR) but unless I am mistaken, it
>>>>> was not as straightforward as we may have thought it might be.
>>>>> Nine of the attributes are described in other specs, so they fit
>>>>> nicely into the tabular format that was suggested back in
>>>>> October's meeting. However, the other eleven needed to be
>>>>> described in the NAP spec and for those I referred to subsequent
>>>>> sections for the details. Looking at the overall result, I'm
>>>>> wondering if this has made the NAP spec less usable for
>>>>> implementers. Some of the necessary information is in the NAP
>>>>> spec itself, some of it needs to be retrieved from one of two
>>>>> other documents, and some of it needs to be retrieved from yet
>>>>> another document (PA-TNC) that is referenced by one of the
>>>>> referenced documents (HCD-ATR).
>>>>>
>>>>> Maybe it would be better to fully specify things in the NAP
>>>>> spec? I realize that this will place the same information in two
>>>>> documents and risking that they lose sync with one another, but
>>>>> ultimately I think we want a binding spec to be implementer-
>>>>> friendly.
>>>>>
>>>>> Let's discuss on Thursday's call...
>>>>> --
>>>>> Regards,
>>>>> Brian Smithson
>>>>> PM, Security Research
>>>>> PMP, CISSP, CISA, ISO 27000 PA
>>>>> Advanced Imaging and Network Technologies
>>>>> Ricoh Americas Corporation
>>>>> (408)346-4435
>>>>>
>>>>>
>>>>> Nevo, Ron wrote:
>>>>>>
>>>>>>
>>>>>> New NAP binding spec. updated by Brian is now posted.
>>>>>>
>>>>>> ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-ids-napsoh10-20090130_ncb.pdf
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Ron Nevo
>>>>>>
>>>>>> Senior Product Manager
>>>>>>
>>>>>> Information Security, DVM, Standards and Compliance
>>>>>>
>>>>>> Sharp Imaging and Information Company of America
>>>>>>
>>>>>> www.sharpusa.com/products/applications/home/
>>>>>>
>>>>>> ______________________________________________
>>>>>>
>>>>>> Sharp Plaza Mahwah NJ 07430 nevor@sharpsec.com
>>>>>>
>>>>>> Phone: 201-760-3937 Fax: 201-529-9673 Cell: 201-220-5945
>>>>>>
>>>>>> The contents of this email are the property of the sender.
>>>>>>
>>>>>> If it was not addressed to you, you have no legal right to read
>>>>>> it .
>>>>>>
>>>>>> If you think you received it in error, please notify the sender.
>>>>>>
>>>>>> Do not forward or copy without permission of the sender.
>>>>>>
>>>>>> "Be Secure. Be Sharp."
>>>>>>
>>>>>>
>>>>
>>
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2009 - 15:23:53 EST